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ABSTRACT 


Malicious  Activity  Simulation  Tool  (MAST)  provides  an  on-the-job-training 
medium  for  information  system  operators  to  practice  responding  to  cyber  threats 
simulated  on  the  operational  information  systems  that  they  manage  day-to-day. 
Because  MAST  has  the  capability  to  simulate  various  cyber  attacks,  it  is 
important  to  measure  the  risk  the  system  poses  to  the  information  systems  on 
which  it  will  operate. 

This  thesis  analyzes  MAST’s  security  posture  and  proposes  potential 
solutions  to  any  vulnerability  discovered  in  that  analysis.  The  analysis  is  based 
on  a  Security  Control  Assessment  (SCA)  utilizing  the  Defense  Information 
Systems  Agency  Application  Security  and  Development  Security  Technical 
Implementation  Guide.  Following  the  SCA,  a  threat  model  is  used  to  determine 
mitigations  to  technical  findings.  Outputs  from  this  research  will  enable  a  more 
secure  implementation  of  MAST. 
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I.  INTRODUCTION 


Cybersecurity  continues  to  be  one  of  the  most  difficult  challenges  for  the 
Department  of  Defense  (DOD).  Adversary  tactics  are  always  evolving,  as  are  the 
information  technology  environments  that  they  attack.  Operators  remain 
challenged  to  keep  up  with  this  tumult  and  must  undergo  constant  training  in 
order  to  remain  competitive  with  their  adversaries.  Existing  platforms,  such  as 
classroom  training  and  various  web-  and  computer-based  training,  offer  a 
baseline  of  educational  opportunity.  However,  they  often  do  not  provide 
experiences  immediately  and  directly  applicable  to  the  environments  operators 
regularly  manage. 

Malicious  Activity  Simulation  Tool  (MAST)  provides  a  unique  opportunity 
for  information  system  operators  to  seize  on-the-job-training  and  practice 
responding  to  cyber  threats  simulated  on  the  operational  information  systems 
that  they  manage  day-to-day.  MAST  is  a  software  suite  that  allows  for  simulated 
malware  activity  on  operational  platforms.  It  creates  the  opportunity  for  practical 
training  of  defending  the  information  systems  that  operators  are  charged  to 
operate,  manage  and  protect. 

Before  the  MAST  opportunity  can  be  seized,  it  is  important  to  measure  the 
risk  the  system  poses  to  the  operational  information  systems  (IS)  that  it  will 
support.  Particularly,  due  to  MAST’s  capability  to  simulate  various  cyber  attacks, 
increased  rigor  must  be  exercised  in  its  assessment.  This  need  for  specialized 
training  is  the  driver  for  this  thesis. 

A.  OBJECTIVES 

The  objective  of  this  research  is  to  analyze  the  security  MAST’s  security 
posture  and  propose  potential  solutions  to  any  vulnerabilities  and  findings  that 
are  identified.  Output  from  this  research  will  form  a  roadmap  for  program 
managers,  developers,  and  user  representatives  in  preparing  MAST  for  an 
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authority  to  operate  (ATO)  on  operational  IT  platforms.  An  ATO  is  required  before 
MAST  can  be  fielded  on  any  operational  platform. 

B.  METHODOLOGY 

The  assessment  contained  in  this  thesis  follows  the  process  discussed  in 
[1],  Particular  emphasis  is  on  the  unique  risk  MAST  represents  as  a  malware 
simulation  platform  designed  to  run  on  production  and  operational  platforms  such 
as  ship  or  installation  networks.  Greater  detail  about  how  the  analysis  is 
conducted  is  discussed  in  Chapter  III,  Security  Analysis  Approach. 

C.  BENEFITS  OF  THIS  RESEARCH  TO  THE  DEPARTMENT  OF  DEFENSE 

AND  DEPARTMENT  OF  THE  NAVY 

As  previously  stated,  MAST  is  unique  in  both  the  mission  it  serves  to 
accomplish  and  the  risk  it  represents  to  the  platforms  and  operators  it  would 
support.  By  conducting  this  assessment,  we  can  create  and  then  execute  a 
roadmap  to  mitigate  or  eliminate  the  risks  presented  by  MAST.  This  will  pave  the 
way  for  deployment  of  MAST  onto  it  target  networks  and  facilitate  richer  and 
more  effective  training  for  cyber  operators. 

D.  THESIS  ORGANIZATION 

This  thesis  is  organized  into  several  chapters,  first  introducing  the 
research  and  the  MAST  system  and  then  documenting  the  approach  for  its 
analysis,  its  findings,  and  ways  to  address  those  findings.  It  concludes  with  a 
summary  of  the  analysis  and  what  steps  should  follow  this  research.  Further 
details  about  the  chapters  are  as  follows. 

Chapter  I  introduces  the  research,  its  objectives,  and  importance.  Chapter 
II  provides  an  overview  of  MAST  as  well  as  prior  research  on  the  program.  It  also 
provides  a  brief  overview  of  a  security  analysis.  Chapter  III  details  specific 
activities,  resources,  tools,  and  techniques  used  in  the  security  analysis  of 
MAST.  Chapter  IV  documents  specific  findings  and  vulnerabilities  discovered  in 
the  security  analysis.  Chapter  V  presents  techniques  and  recommendations  for 
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addressing  the  vulnerabilities  discovered  in  the  security  analysis.  Chapter  VI 
provides  an  executive  summary  of  MAST’s  security  vulnerabilities  and  possible 
methods  to  address  those  findings  as  documented  in  Chapters  IV  and  V. 
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II.  BACKGROUND 


This  chapter  describes  the  architecture  and  usage  of  MAST  and  also 
describes  the  intended  focus  areas  for  the  security  analysis.  [2],  [3],  and  [4]  each 
go  into  significant  detail  about  MAST  architecture,  so  only  cursory  coverage  will 
be  provided  here. 

A.  MAST  ARCHITECTURE 

The  MAST  architecture  is  a  three-tiered  client  server  architecture,  as 
illustrated  in  Figure  1.  It  features  two  server  tiers  and  a  client  tier:  the  MAST 
Scenario  Generation  (SG)  Server,  the  MAST  Scenario  Execution  (SE)  Server, 
and  the  MAST  Clients. 

The  architecture  also  utilizes  two  sets  of  files:  client  module  files,  referred 
to  as  Simware,  and  scenario  files.  Both  sets  are  used  to  guide  and  execute 
scenarios  for  MAST. 
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MAST  Scenario  Generation  Server 


MAST  Scenario  Execution  Server 


Operational  Platform 


Figure  1 .  Simplified  MAST  Architecture 


1.  MAST  Scenario  Generation  Server 

The  SG  Server  is  the  highest  tier  in  the  system’s  architecture.  It  installs  as 
a  simple  Java-based  desktop  application.  It  provides  the  following  capabilities 
and  functions: 

•  Maintains  a  master  library  of  Simware  and  Scenario  files 

•  Deploys  Simware  and  Scenario  files  to  subordinate  MAST  SE 
Servers 
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•  Provides  for  remote  scenario  management 

•  Generates  reports  and  aggregates  data  from  subordinate  MAST 
SE 

2.  MAST  Scenario  Execution  Server 

The  SE  Server  is  the  primary  controller  for  a  scenario  at  an  operational 
platform.  It  is  also  the  first  MAST  product  to  be  deployed  on  an  operation 
platform,  as  opposed  to  the  SG  Server,  which  need  not  be  deployed  on  the 
operational  platform  and  thus  introduces  a  different  risk  to  the  operators’  mission. 
It  provides  the  following  capabilities  and  functions: 

•  Maintains  a  local  library  of  Simware  and  Scenario  files 

•  Deploys  Simware  and  Scenario  files  to  subordinate  MAST  Clients 

•  Receives  status  and  logs  data  from  MAST  Clients 

•  Generates  reports  and  data  aggregates  data  from  subordinate 
MAST  Clients 

•  Maintains  MAST  client  and  Simware  status 

•  Commands  and  controls  all  scenarios  and  MAST  Clients 

•  Performs  “kill  switch”  functionality  allowing  for  emergency  shutdown 
of  a  scenario 

3.  MAST  Client 

The  MAST  Client  is  installed  on  each  endpoint  workstation  running  a 
Microsoft  Windows  operating  system.  It  provides  the  following  capabilities  and 
functions: 

•  Runs  Simware  as  directed  by  MAST  SE 

•  Inventories  host  attributes,  such  as  installed  software  and  profiling 
information,  such  as  Internet  Protocol  (IP)  and  Media  Access 
Control  (MAC)  Addresses 

•  Reports  status  on  scenario  to  MAST  SE 
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4. 


MAST  Simware 


MAST  Simware  provides  the  muscle  for  each  client  to  perform  various 
malware  simulations,  including — but  not  necessarily  limited  to — port  scans, 
antivirus  triggers,  and  rogue  pop-up  advertisements.  Requirements  for  Simware 
and  each  module’s  capabilities  and  functions  will  vary  widely  and  are  often 
tailored  for  specific  scenarios. 

5.  Scenario  Files 

MAST  Scenario  Files  are  intended  to  allow  for  pre-built  and  template 
scenarios  to  be  issued  from  the  SG  Server.  While  not  actual  code,  they  script 
execution  of  MAST  Simware  across  multiple  clients. 

B.  TRUST 

In  this  paper  we  use  trust  to  encompass  the  ability  for  various  parts  of  the 
MAST  architecture,  including  operators  and  developers,  to  ensure  confidentiality, 
integrity,  and  availability  as  protected  throughout  MAST  and  the  operation  of 
MAST. 

Confidentiality,  integrity,  and  availability  are  the  measures  by  which 
cybersecurity  is  assessed.  The  quality  that  security  controls  persevere  in  these 
areas  can  demonstrate  how  well  an  application  or  system  protects  itself,  its  data, 
and  its  users.  Brief  definitions  of  each  of  the  three  focus  areas  are  as  follows,  as 
provided  in  [5]: 

•  Confidentiality — The  property  that  information  is  not  disclosed  to 
system  entities  (users,  processes,  devices)  unless  they  have  been 
authorized  to  access  the  information. 

•  Integrity — The  property  whereby  an  entity  has  not  been  modified  in 
an  unauthorized  manner. 

•  Availability — The  property  of  being  accessible  and  usable  upon 
demand  by  an  authorized  entity. 
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Trust,  as  it  is  referred  to  in  this  paper,  roughly  equates  to  the  trust  as  a 
concept  in  [6];  trust  is  a  property  of  an  entity  to  do  as  it  is  specified.  When 
measuring  trust,  we  refer  to  an  object’s  trustworthiness. 

Trustworthiness  of  information  systems  such  as  MAST  is  measured  by 
how  the  information  system  uses  defenses — known  as  security  controls — to 
defend  itself  against  potential  environmental  and  human  driven  threats,  ranging 
from  malfunction  to  malicious.  A  security  control  assessment  evaluates  the 
adequacy  in  which  the  security  controls  reduce  risk. 

C.  RISK  MANAGEMENT  FRAMEWORK 

A  security  control  assessment  produces  the  results  and  artifacts  that  are 
consumed  in  the  Risk  Management  Framework  (RMF)  as  documented  in  [7], 
RMF  replaces  the  Department  of  Defense  Information  Assurance  Certification 
and  Accreditation  Process  (DIACAP).  The  DOD  RMF  is  better  honed  to  build 
security  functionality  and  management  processes  early  into  an  information 
system’s  life  cycle  and  incorporate  continuous  monitoring  of  a  system’s  posture 
and  risk  well  after  its  initial  authorization  to  operate. 

The  Risk  Management  Framework  (RMF)  consists  of  six  steps.  These 
steps  are  not  necessarily  required  to  be  in  this  order,  however,  as  the  RMF  was 
designed  to  align  to  a  development  life  cycle  this  is  the  ideal  order.  It  should  be 
noted  that  RMF  may  be  applied  to  a  legacy  system  that  is  already  fielded 
however  some  gap  analysis  and  assessment  may  be  required. 

The  RMF  steps  are  briefly  discussed  in  the  following  sections.  Since  the 
focus  of  this  thesis  isn’t  to  analyze  RMF,  only  a  cursory  discussion  will  be 
included.  Refer  to  [7]  for  further  details. 
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(1)  Step  1:  Categorize  Information  System 

In  this  step  the  system’s  threats  and  the  information  types  it  processes  are 
determined. 

(2)  Step  2:  Select  Security  Controls 

In  this  step  the  security  controls  that  will  be  implemented  to  address 
system  threats  and  information  types  it  processes  are  determined.  The  system 
security  plan  and  continuous  monitoring  strategy  are  also  finalized. 

(3)  Step  3:  Implement  Security  Controls 

In  this  step  security  controls  are  implemented  and  deployed.  Supporting 
documentation  is  also  updated. 

(4)  Step  4:  Assess  Security  Controls 

In  this  step  a  security  control  assessment  is  conducted  against  the 
information  system.  The  output  is  equivalent  to  the  “certification”  task  of 
traditional  C&A. 

(5)  Step  5:  Authorize  Information  System 

In  this  step,  a  Plan  of  Action  and  Milestones  (POAM)  is  created  based  on 
findings  from  Step  4.  A  POAM  and  other  artifacts  are  bundled  together  in  a 
security  authorization  package,  along  with  a  risk  determination  and  presented  to 
an  Authorizing  Official  for  risk  acceptance.  This  is  equivalent  to  the 
“accreditation”  task  of  traditional  C&A. 

(6)  Step  6:  Monitor  Security  Controls 

In  this  step  typical  system  maintenance  occurs  to  include  configuration 
management  and  vulnerability  management.  Outstanding  POAM  items  are  also 
addressed. 
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D.  SECURITY  CONTROL  ASSESSMENT 

As  defined  in  The  Committee  on  National  Security  Systems  National 
Information  Assurance  (IA)  Glossary  [5],  a  security  control  assessment  (SCA)  is: 

The  testing  and/or  evaluation  of  the  management,  operational,  and 
technical  security  controls  to  determine  the  extent  to  which  the 
controls  are  implemented  correctly,  operating  as  intended,  and 
producing  the  desired  outcome  with  respect  to  meeting  the  security 
requirements  for  the  system  or  enterprise. 

The  practice  of  conducting  a  security  control  assessment  is  typically  a 
critical  step  in  acquiring  authorization  to  operate  an  information  system.  For 
example,  [8]  requires  that  IT  Product  Information  System  Security  Managers 
(ISSM)  ensure  their  system  undergoes  a  SCA. 

The  SCA  conducted  on  MAST  as  part  of  the  research  for  this  thesis 
comprises  the  [1],  Further  details  on  how  the  STIG  is  applied  to  MAST  will  be 
discussed  in  Chapter  III,  Security  Control  Assessment  Approach. 
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III.  SECURITY  CONTROL  ASSESSMENT  APPROACH 


The  ASD  STIG  [1]  remains  the  core  component  of  the  SCA  conducted  in 
this  research.  It  represents  significant  research  in  an  application  development  life 
cycle  within  the  DOD,  drawing  on  knowledge  and  capability  from  resources  such 
as  the  National  Institute  of  Standards  and  Technology,  the  Microsoft  Corporation, 
the  MITRE  Corporation,  and  the  Open  Web  Application  Security  Project 
(OWASP)  [1], 

The  ASD  STIG  [1]  divides  an  SCA  into  five  areas  built  around  a  Software 
Development  Life  Cycle  (SDLC).  The  advantage  to  this  approach  is  that 
application  developers  can  advance  with  greater  ease  through  development  and 
implementation  of  the  STIG  as  they  develop  their  application. 

Areas  in  [1]  that  are  not  applicable  to  MAST  are  omitted  from  discussion  in 
this  chapter.  For  example,  security  concerns  specific  to  web  technologies  will  not 
be  discussed  as  those  technologies  are  not  in  use  by  MAST. 

A.  PROGRAM  MANAGEMENT  CONSIDERATIONS 

Program  management  focuses  on  planning  functions  of  an  application’s 
development.  Of  the  158  tests  in  [1],  16  emphasize  program  management. 
Analysis  steps  in  this  area  focus  on  system  documentation  and  planning 
processes,  as  well  as  the  beginning  stages  of  application  deployment. 
Interestingly,  half  of  the  checks  that  apply  to  program  management  also  apply  to 
deployment. 

(1)  Documentation 

The  first  stage  of  reviewing  for  program  management  considerations 
includes  documentation  review.  Particular  artifacts  to  assess  include: 

•  System  Security  Plan  (SSP) — A  keystone  artifact  that  documents 
all  security  aspects  of  a  program.  It  is  often  a  primary  artifact  in  a 
package  forwarded  to  an  authorizing  official  when  applying  for  an 
authority  to  operate. 
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•  Application  Configuration  Guide — A  document  that  captures  how  an 
application  is  to  be  deployed  in  its  target  environment.  It  often  also 
includes  information  on  securing  the  application  in  accordance  with 
the  controls  and  capabilities  documented  in  the  SSP. 

•  Information  System  Categorization — This  is  the  determination  of 
system’s  confidentiality,  Integrity,  and  availability  requirements. 

•  Security  Classification  Guide — For  systems  that  process  classified 
information,  this  document  should  detail  what  data  elements  are 
actually  classified,  their  classification,  and  handling  instructions. 

•  Coding  Standards — This  artifact  informs  developers  of  expectations 
for  producing  source  code.  Details  vary  from  naming  conventions  to 
spacing  and  readability. 

Program  management  tests  also  include  a  review  of  training  and 
maintenance  program  maturity. 

(2)  Education  and  Training 

Education  and  training  material  is  expected  to  be  developed  for  various 
stakeholders  tied  to  development  of  an  information  system.  This  includes 
managers,  developers,  and  testers.  As  the  focus  of  program  management  at  this 
stage  is  development  of  a  product,  training  for  systems  users  is  not  considered  in 
scope. 


(3)  Application  Maintenance 

Application  Maintenance  addresses  processes  that  support  the  application 
through  discovery  and  remediation  of  flaws. 

B.  DESIGN  AND  DEVELOPMENT  CONSIDERATIONS 

Design  and  development  focuses  on  the  actual  creation  of  an  information 
system.  Of  the  158  tests  in  [1],  103  pertain  to  design  and  development,  by  far  the 
largest  focus  for  the  guide.  Analysis  steps  in  this  area  focus  on  assessing  how 
well  security  was  built  in  throughout  creation  of  the  information  system  and  range 
across  many  technologies  areas. 
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(1)  Documentation 

The  first  stage  of  reviewing  for  design  and  development  considerations 
includes  documentation  review.  Particular  artifacts  to  assess  include: 

•  Design  Document — This  artifact  addresses  the  information 
systems’  architecture.  It  has  several  security  related  requirements 
dealing  with  interfaces,  authentication,  and  information  types. 

•  Application  Configuration  Guide — This  is  the  same  document 
identified  in  program  management. 

•  Threat  Model — This  artifact  represents  the  efforts  made  by  the 
developer  to  identify  threats  that  an  information  system  may 
encounter  and  based  on  the  risk  each  threat  represents,  determine 
adequate  controls  against  those  threats.  It  is  not  uncommon  for  the 
threat  model  to  be  a  component  of  the  design  document. 

(2)  Best  Practices 

The  next  area  in  the  design  and  development  consideration  includes 
various  steps  and  measures  that  improve  the  security  of  an  information  system 
but  do  not  fit  into  any  of  the  other  areas  discussed  later  in  the  chapter.  This 
includes: 

•  Removal  of  “dead  code.”  Dead  code  is  code  that  has  no  path  for 
execution. 

•  Separation  of  data  and  presentation  services.  A  common  example 
of  meeting  this  requirement  would  be  installing  web  servers  and 
database  servers  on  separate  hardware  or  systems. 

•  Quality  assurance  measures  such  as  ensuring  that  directories  and 
file  paths  are  valid. 

•  Application  clean  up  measures  such  as  deleting  temporary  files  at 
the  end  of  application  sessions. 

•  Secure  default  configurations  such  that  when  the  application  is 
installed  or  deployed  it  is  already  configured  to  be  as  secure  as 
possible. 

•  Comprehensive  error  handlings  so  that  application  failure  does  not 
allow  the  application  to  enter  into  an  insecure  state. 
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(3)  Cryptography 

The  cryptography  area  assesses  whether  or  not  approved  cryptographic 
algorithms  and  technologies  are  utilized  by  an  information  system,  where 
encryption  is  required.  Particular  requirements  mandate  certification  and  National 
Security  Agency  (NSA)  approval  for  classified  communications  [9], 

(4)  Data 

The  data  area  assesses  how  the  application  stores  and  transmits  data  as 
well  as  how  it  connects  to  its  data  sources.  The  ASD  STIG  [1]  requires 
encryption  of  data  at  rest  and  in  transit. 

(5)  Authentication 

The  authentication  area  assesses  how  an  application  performs 
identification  of  users  and  resources.  This  part  of  the  assessment  has  checks 
that  vary  depending  on  the  technology  and  authentication  requirements  for  the 
application.  For  example,  a  desktop  application  that  does  not  utilize  networking 
technologies  will  have  far  fewer  requirements  than  a  typical  web  server/ 
database  server  application. 

(6)  Access  Control 

The  access  control  area  assesses  how  an  application  grants  access  to 
various  parts  of  itself.  This  part  of  the  assessment  reviews  access  control  models 
and  principles,  particularly  role-based  access  control  and  least  privilege 
principles. 

(7)  Input  Validation 

Within  design  and  development  considerations,  input  validation  assesses 
how  an  application  verifies  the  validity  of  any  data  that  crosses  its  trust  boundary. 
This  part  of  the  assessment  reviews  how  the  application  has  established  criteria 
for  acceptable  input  and  how  it  defends  itself  against  known  input  validation 
exploits.  Particular  vulnerabilities  of  interest  are: 
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•  SQL  Injection  Vulnerabilities — Vulnerabilities  where  an  attacker 

manipulates  application  queries  in  order  to  modify  or  access  data  or 
direct  other  unauthorized  activity  of  the  database  or  application 
servers. 

•  Integer  Arithmetic  Vulnerabilities — Vulnerabilities  where  an 

application  generates  unpredictable  results  from  integer  math.  This 
occurs  due  to  the  nature  of  integers  having  multiple  sizes, 
signed/unsigned  variants,  and  overflow  properties. 

•  Format  String  Vulnerabilities — Vulnerabilities  where  an  attacker 

passes  string  values  specifically  formatted  for  actions  for  which  the 
application  is  not  designed. 

•  Command  Injection  Vulnerabilities — Vulnerabilities  where  an 

attacker  uses  a  data  injection  vulnerability  to  execute  arbitrary 
commands  via  the  application. 

•  Cross  Site  Scripting  (XSS)  Vulnerabilities — Vulnerabilities  where  an 
attacker  uploads  malicious  code  to  a  vulnerable  website,  allowing 
for  a  third  party  victim  to  be  exploited. 

•  Cross  Site  Request  Forgery  (CSRF)  Vulnerabilities — Vulnerabilities 
where  an  attacker  uses  specially  crafted  HTML  to  abuse  persistent 
authentication  a  user  may  have  to  another  application. 

•  Buffer  Overflow  Vulnerabilities — Vulnerabilities  where  an  attacker 

may  write  data  beyond  the  allocated  memory  of  the  buffer  with 
which  he  or  she  is  interacting. 

(8)  Canonical  Representation 

The  canonical  representation  assesses  how  an  application  handles  the 
name  representation  of  a  resource.  This  vulnerability  is  most  common  for  files 
where  the  operating  systems  on  which  the  application  resides  may  have  multiple 
ways  to  represent  such  files. 

(9)  Application  Information  Disclosure 

The  application  information  disclosure  area  assesses  the  extent  to  which 
an  application  limits  disclosure  of  information  that  aids  an  attacker  in  exploiting 
the  application.  Poorly  designed  applications  will  disclose  valuable  information 
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that  facilitates  a  simpler  reconnaissance  for  an  attacker,  increasing  the  likelihood 
of  compromise. 

(10)  Race  Conditions 

The  race  conditions  area  assesses  how  well  an  application  manages 
multiple  processes  and  or  threads  in  an  application.  Race  conditions  become 
most  common  when  multiple  processes  or  threads  need  access  to  a  single 
resource. 

(11)  Auditing 

The  auditing  area  assesses  how  well  an  application  audits  its  behavior 
and  that  of  the  users  and  resources  that  interact  with  it. 

(12)  Mobile  Code 

The  mobile  code  assesses  the  application’s  use  of  mobile  code.  The 
Committee  on  National  Security  Systems  National  Information  Assurance  (IA) 
Glossary  [5]  defines  mobile  code  as: 

Software  programs  or  parts  of  programs  obtained  from  remote 

information  systems,  transmitted  across  a  network,  and  executed 

on  a  local  information  system  without  explicit  installation  or 

execution  by  the  recipient. 

(13)  Internet  Protocol  Version  6 

The  Internet  Protocol  Version  6  (IPV6)  area  in  the  design  and 
development  considerations  assesses  whether  an  application  is  capable  of 
operating  in  an  IPV6  environment  as  well  as  how  well  it  maintains  its 
interoperability  with  IPV4  environments. 
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C.  SOFTWARE  CONFIGURATION  MANAGEMENT  CONSIDERATIONS 

Software  Configuration  Management  (SCM)  considerations  focus  on  the 
creation  of  an  information  system.  Of  the  158  tests  in  [1],  only  4  emphasize  SCM. 
Analysis  steps  in  this  area  focus  on  assessing  how  well  configuration  of  the 
application  was  managed  over  the  course  of  its  development  life  cycle. 

(1)  Software  Configuration  Management  Plan 

The  SCM  plan  area  assesses  the  maturity  of  the  SCM  program.  The  key 
artifact  for  this  review  is  the  SCM  plan.  The  SCM  Plan  is  expected  to  identify  a 
myriad  of  relevant  data  regarding  the  application  including: 

•  Roles  and  responsibilities  during  development  of  the  application. 

•  Tools,  techniques  and  methodologies  used  to  develop  the 
application. 

•  Version  and  release  schedules  for  the  application. 

(2)  Configuration  Control  Board  (CCB). 

The  Configuration  Control  Board  (CCB)  area  assesses  the  establishment 
of  a  CCB. 

(3)  File  Integrity 

The  file  integrity  assesses  what  measures  ensure  secure  transfer  of 
application  files.  Cryptographic  hash  technology  is  used  to  determine  whether  or 
not  files  have  been  tampered  with. 

D.  TESTING  CONSIDERATIONS 

Testing  considerations  focus  on  the  security-focused  testing  of  an 
information  system.  Of  the  158  tests  in  [1],  only  11  are  specific  to  testing. 
Analysis  steps  in  this  area  focus  on  identifying  security  issues  before  the 
application  is  released.  For  the  purpose  of  this  research  functional  testing  and 
other  types  of  testing  are  not  considered. 
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(1 )  Test  Plans  and  Procedures 

The  test  plans  and  procedure  area  assesses  whether  or  not  test 
procedures  have  been  created  and  executed  before  release  of  the  software  and 
also  ensures  those  tests  are  executed  regularly. 

(2)  Fuzz  Testing 

The  fuzz  testing  area  assesses  whether  the  application  has  had  its  various 
data  input  vectors  tested  for  tolerance  to  malicious  data. 

(3)  Code  Coverage 

The  code  coverage  area  assesses  how  completely  security  testing 
addresses  the  application  as  a  percentage  of  total  code.  Program  and  Test 
managers  seek  to  get  as  close  to  100%  as  possible  with  low  test  values 
indicating  a  flaw  in  the  test  program. 

(4)  Code  Reviews 

The  code  review  area  assesses  the  processes  used  to  review  source 
code  of  the  application.  While  code  review  typically  addresses  functional  issues 
in  the  application,  in  this  context  security  issues  are  the  only  focus. 

E.  DEPLOYMENT  CONSIDERATIONS 

Deployments  considerations  focus  on  security  concerns  of  the  application 
after  is  has  been  released  and  has  been  deployed  to  its  intended  operating 
environment.  Of  the  158  tests  in  [1],  48  emphasize  on  deployment  issues. 

(1)  Documentation 

The  first  stage  of  reviewing  for  deployment  considerations  includes 
documentation  review.  The  first  three  documents  should  have  been  assessed  in 
the  program  management  considerations  review  and  the  last  in  design  and 
development  considerations  review.  Particular  artifacts  to  assess  include: 

•  System  Security  Plan  (SSP) 

•  Application  Configuration  Guide 
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•  Security  Classification  Guide 

•  Threat  Model 

(2)  Third-Party  Software 

The  third  party  software  area  in  the  deployment  considerations  assesses 
how  third  party  products  are  configured  and  hardened  when  deployed  with  the 
application. 

(3)  Ports  and  Protocols 

The  ports  and  protocols  area  assesses  what  ports  and  protocols  an 
application  with  network  capabilities  uses  for  communication.  Both  secure  use 
and  registration  in  the  DOD  Ports,  Protocols,  and  Services  database  are 
assessed. 

(4)  Workplace  Security  Procedures 

The  workplace  security  procedures  area  assesses  traditional  security 
measures  implemented  to  protect  physical  assets  of  the  application. 

(5)  Unnecessary  Services 

The  unnecessary  services  area  reviews  removal  or  disabling  services  and 
protocols  not  in  use  by  the  application. 

(6)  Application  Maintenance 

The  application  maintenance  area  assesses  the  framework  to  support  the 
application  during  and  after  deployment.  Here  vulnerability  and  patch 
management  programs  are  reviewed. 

(7)  Security  Incident  Response  Process 

The  security  incident  response  process  area  assesses  the  maturity  of  the 
incident  response  process. 
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(8)  Denial  of  Service 

The  Denial  of  Service  (DoS)  area  assesses  the  applications  resilience  to 
DoS  attacks.  A  DoS  attack  is  any  malicious  activity  designed  to  impede  the 
availability  of  its  target.  The  assessment  includes  both  resilience  of  the 
application  and  the  environment  in  which  it  is  installed. 

(9)  Access  Control 

The  access  control  area  assesses  the  permissions  and  configuration  of 
application  files.  In  particular,  the  assessment  determines  if  the  application 
configuration  files  are  configured  such  that  only  authorized  personnel  my  modify 
them. 

(10)  Database  Exports 

The  database  exports  area  assesses  the  processes  in  place  to  ensure 
exports  of  the  deployed  production  database  to  an  application  are  purged  of  any 
sensitive  information  before  being  used  in  development  or  testing  environments. 

(11)  Public  Key  Infrastructure  Certificate  Configuration 

The  Public  Key  Infrastructure  (PKI)  certificate  configuration  area  assesses 
whether  or  not  the  application  has  been  configured  to  utilize  the  DOD  PKI  for 
authentication  and  only  that  infrastructure. 

(12)  Auditing 

The  auditing  area  assesses  the  depth  and  breadth  of  application  audit 
logging  as  well  as  how  those  logs  are  protected  and  maintained. 

(13)  Recovery  and  Contingency  Planning 

The  recovery  and  contingency  planning  area  assesses  the  completeness 
of  the  application  continuity  plans  including  all  relevant  recovery  procedures. 

(14)  Account  Management 
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The  account  management  area  assesses  established  processes  for 
account  use,  creation,  modification  and  deletion.  Some  of  the  areas  of  focus 
include: 

•  Password  security 

•  Password  complexity 

•  Shared  user  accounts 

•  Privileged  access 

•  Service  and  Application  accounts 

•  Least  privilege  policies 

(15)  Infrastructure  Compliance 

The  infrastructure  compliance  area  in  the  deployment  considerations 
assesses  the  documented  and  confirmed  security  requirements  and  compliance 
with  those  security  requirements  for  the  environment  that  hosts  the  application. 

(16)  Enclave  Demilitarized  Zone 

The  enclave  Demilitarized  Zone  (DMZ)  area  assesses  placement  of 
application  that  communicates  across  external  enclave  boundaries  in  a  DMZ. 

(17)  DOD  DMZ 

The  infrastructure  compliance  area  assesses  placement  of  an  Internet 
facing  application  within  specially  demarcated  DMZ  for  outside  the  Department  of 
Defense  Information  Networks  (DODIN) 

F.  SUMMARY 

In  this  chapter,  the  SCA  approach  used  in  this  research  was  discussed. 
The  five  consideration  areas,  program  management,  design  and  development, 
software  configuration  management,  testing,  and  deployment,  were  enumerated, 
including  the  focus  areas  that  compose  them.  The  following  chapter  will  describe 
the  findings  that  result  from  applying  this  SCA  approach  to  MAST. 
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IV.  ASSESSMENT  FINDINGS 


Findings  discovered  during  this  research  are  organized  as  they  are  in  [1], 
As  outlined  in  Appendix  A,  some  findings  apply  to  multiple  considerations;  those 
findings  will  be  annotated  and  discussed  in  both  areas  that  they  apply  to. 

A.  ASSESSMENT  ORGANIZATION 

Each  STIG  Item,  represented  by  a  unique  SITG  ID  later  in  the  chapter,  is 
assessed  a  raw  severity  category  by  [1],  Table  1,  DISA  Severities,  lists  those 
severities. 


Table  1.  DISA  Severities,  after  [1] 


Severity 

Severity  Meaning 

High 

CAT  1 

Any  vulnerability,  the  exploitation  of  which  will,  directly 
and  immediately  result  in  loss  of  Confidentiality, 
Availability,  or  Integrity. 

Moderate 

CAT  II 

Any  vulnerability,  the  exploitation  of  which  has  a 
potential  to  result  in  loss  of  Confidentiality,  Availability, 
or  Integrity. 

Low 

CAT  III 

Any  vulnerability,  the  existence  of  which  degrades 
measures  to  protect  against  loss  of  Confidentiality, 
Availability,  or  Integrity. 

A  result  from  a  particular  STIG  check  will  be  one  of  the  statuses  identified 
in  Table  2,  STIG  Check  Status.  Typically  SCAs  focus  on  findings  vice  satisfied 
requirements,  so  unless  there  is  an  item  of  particular  interest,  only  open  findings 
will  be  addressed. 
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Table  2.  STIG  Check  Status 


Status 

Status  Description 

Not  a  Finding 

A  STIG  check  is  considered  “Not  a  Finding'1  when  the 
application  being  assessed  meets  the  requirement  in 
the  STIG  check. 

Not  Applicable 

A  STIG  check  is  considered  “Not  applicable"  when  the 
requirement  that  the  STIG  check  is  assessing  is  not 
relevant  to  the  application  being  assessed. 

Open 

A  STIG  check  is  considered  “Open"  when  the 
requirement  that  the  STIG  check  is  assessing  is  not 
met.  Typically  the  check  will  clearly  indicate  what 
noncompliantbehavioror  observation  drives  towards  a 
finding. 

B.  OVERVIEW  OF  FINDINGS 

The  SCA  for  MAST  culminated  in  the  overall  findings  described  in  Table  3, 
Overall  Summary  of  Findings.  With  nine  (9)  open  CAT  I  findings,  MAST  is 
considered  to  have  High  Risk. 


Table  3.  Overall  Summary  of  Findings 


Severity 

Not  A  Finding 

Not  Applicable 

Open 

CAT  1 

7 

17 

9 

CAT  II 

15 

36 

62 

CAT  III 

2 

4 

6 
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C.  PROGRAM  MANAGEMENT  FINDINGS 

Table  4,  Summary  of  Program  Management  Findings,  provides  a  numeric 
summary  of  the  findings  in  program  management. 


Table  4.  Summary  of  Program  Management  Findings 


Severity 

Not  A  Finding 

Not  Applicable 

Open 

CAT  1 

1 

0 

0 

CAT  II 

2 

0 

12 

CAT  III 

1 

0 

0 

Table  5,  Program  Management  Findings  Details,  describes  specific 
findings  related  to  program  management.  The  findings  are  non-technical  in 
nature.  While  this  may  be  disarming  initially,  findings  here  will  generate  systemic 
vulnerability  throughout  the  entire  life  cycle  of  the  application. 


Table  5.  Program  Management  Findings  Details,  after  [1] 


STIG  ID 
Severity 

Requirement  from  ASD 
STIG 

Finding  Details  from  SCA 

APP2020 

Medium 

The  Program  Manager  will 
provide  an  Application 
Configuration  Guide  to  the 
application  hosting  providers 
to  include  a  list  of  all  potential 
hosting  enclaves  and 
connection  rules  and 
requirements. 

Application  does  not  have  an 
Application  Configuration  Guide. 

APP2050 

Medium 

The  Program  Manager  will 
ensure  the  system  has  been 
assigned  specific  Mission 
Assurance  Category  (MAC) 
and  confidentiality  levels. 

System  has  not  been  assigned  a 

MAC  or  confidentiality  level. 
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STIG  ID 
Severity 

Requirement  from  ASD 
STIG 

Finding  Details  from  SCA 

APP2060 

Medium 

The  Program  Managerwill 
ensure  the  developmentteam 
follows  a  set  of  coding 
standards. 

Written  record  showing 
implementation  of  coding  standards 
not  available. 

APP2110 

Medium 

The  Program  Manager  and 
designerwill  ensure  the 
application  is  registered  with 
the  DOD  Ports  and  Protocols 
Database. 

Application  registration  in  the  DOD 
Ports  and  Protocols  Database  has 
not  yet  been  completed. 

APP2120 

Medium 

The  Program  Managerwill 
ensure  all  levels  of  program 
management,  designers, 
developers,  and  testers 
receive  the  appropriate 
security  training  pertaining  to 
their  job  function. 

No  documentation  exists  ensuring 
all  levels  of  program  management, 
designers,  developers,  and  testers 
receive  the  appropriate  security 
training  pertaining  to  their  job 
function. 

APP2130 

Medium 

The  Program  Managerwill 
ensure  a  vulnerability 
managementprocess  is  in 
place  to  include  ensuring  a 
mechanism  is  in  place  to 
notify  users,  and  users  are 
provided  with  a  means  of 
obtaining  security  updates  for 
the  application. 

The  vulnerability  management 
process  is  not  documented. 

APP2140 

Medium 

The  Program  Managerwill 
ensure  a  security  incident 
response  process  forthe 
application  is  established  that 
defines  reportable  incidents 
and  outlines  a  standard 
operating  procedure  for 
incident  response  to  include 
Information  Operations 
Condition  (INFOCON). 

A  security  incident  response  process 
is  not  documented. 
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STIG  ID 
Severity 

Requirement  from  ASD 
STIG 

Finding  Details  from  SCA 

APP2150 

Medium 

The  Program  Managerwill 
ensure  procedures  are 
implemented  to  assure 
physical  handling  and  storage 
of  information  is  in 
accordance  with  the  data’s 
sensitivity. 

Procedures  assure  physical 
handling  and  storage  of  information 
is  in  accordance  with  the  data’s 
sensitivity  are  not  documented. 

APP2040 

Medium 

If  the  application  contains 
classified  data,  the  Program 
Managerwill  ensure  a 

Security  Classification  Guide 
exists  containing  data 
elements  and  their 
classification. 

Because  MAST  could  be  installed 
on  a  classified  system,  it  requires  a 
Security  Classification  Guide  in 
order  to  manage  any  outputs  from 
the  tool. 

APP2100 

Medium 

The  Program  Managerand 
designerwill  ensure  the 
application  design  complies 
with  the  DOD  Ports  and 
Protocols  guidance. 

DOD  Ports,  Protocols,  and  Services 
(PPS)  Vulnerability  Analysis 
compliance  has  not  yet  been 
determined.  Also,  new  protocol  is 
being  deployed  to  operate  the 
application.  The  new  protocol  must 
be  submitted  to  DOD  for  risk 
assessment. 

APP2010 

Medium 

The  Program  Managerwill 
ensure  a  System  Security 

Plan  (SSP)  is  established  to 
describe  the  technical, 
administrative,  and  procedural 
IA  program  and  policies 
governing  the  DOD 
information  system,  and 
identifying  all  IA  personnel 
and  specific  IA  requirements 
and  objectives. 

Application  does  not  have  a  System 
Security  Plan  (SSP). 
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STIG  ID 
Severity 

Requirement  from  ASD 
STIG 

Finding  Details  from  SCA 

APP2160 

Medium 

The  Program  Manager  and 

IAO  will  ensure  development 
systems,  build  systems,  test 
systems,  and  all  components 
comply  with  all  appropriate 
DOD  STIGs,  NSA  guides,  and 
all  applicable  DOD  policies. 

The  Test  Managerwill  ensure 
both  client  and  server 
machines  are  STIG  compliant. 

Developmentis  conducted  on  a  non- 
STIG-compliant  platform. 

D.  DESIGN  AND  DEVELOPMENT  FINDINGS 

Table  6,  Summary  of  Design  and  Development  Findings,  provides  a 
numerical  summary  of  the  findings  in  design  and  development. 


Table  6.  Summary  of  Design  and  Development  Findings 


Severity 

Not  A  Finding 

Not  Applicable 

Open 

CAT  1 

6 

13 

8 

CAT  II 

12 

27 

33 

CAT  III 

1 

2 

1 

Table  7,  Design  and  Development  Findings  Details,  describes  specific 
findings  in  design  and  development.  The  findings  are  a  mix  of  technical  and  non¬ 
technical. 
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Table  7.  Design  and  Development  Findings  Details,  after  [1] 


STIG  ID 
Severity 

Requirement  from  ASD 

STIG 

Finding  Details  from  SCA 

APP2020 

Medium 

The  Program  Managerwill 
provide  an  Application 
Configuration  Guide  to  the 
application  hosting  providers 
to  include  a  list  of  all  potential 
hosting  enclaves  and 
connection  rules  and 
requirements. 

Application  does  not  have  an 
Application  Configuration  Guide. 

APP2060 

Medium 

The  Program  Managerwill 
ensure  the  developmentteam 
follows  a  set  of  coding 
standards. 

Written  record  showing 
implementation  of  coding  standards 
is  not  available. 

APP2100 

Medium 

The  Program  Manager  and 
designerwill  ensure  the 
application  design  complies 
with  the  DOD  Ports  and 
Protocols  guidance. 

DOD  Ports,  Protocols,  and  Services 
(PPS)  Vulnerability  Analysis 
compliance  has  not  yet  been 
determined.  Also,  a  new  protocol  is 
being  deployed  to  operate  the 
application  that  has  not  been 
registered  per  instruction  [10]. 

APP2110 

Medium 

The  Program  Manager  and 
designerwill  ensure  the 
application  is  registered  with 
the  DOD  Ports  and  Protocols 
Database. 

Application  registration  in  the  DOD 
Ports  and  Protocols  Database  has 
not  yet  been  completed. 

APP3010 

Medium 

The  designerwill  create  and 
update  the  Design  Document 
for  each  release  of  the 
application. 

Application  does  not  have  a  Design 
Document. 

APP3020 

Medium 

The  designerwill  ensure 
threat  models  are 
documented  and  reviewed  for 
each  application  release  and 
updated  as  required  by 
design  and  functionality 
changes  or  new  threats  are 
discovered. 

A  threat  model  was  not  developed 
for  the  application. 
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STIG  ID 
Severity 

Requirement  from  ASD 

STIG 

Finding  Details  from  SCA 

APP3100 

Medium 

The  Designerwill  ensure  the 
application  removes 
temporary  storage  of  files  and 
cookies  when  the  application 
is  terminated. 

Application  does  not  store  temporary 
authentication  data,  howeverserver 
does  not  clean  up  logs,  which  may 
contain  sensitive  information  due  to 
the  mission  and  capability  of  this 
software. 

APP3150 

Medium 

The  designerwill  ensure  the 
application  uses  the  Federal 
Information  Processing 
Standard  (FIPS)  140-2 
validated  cryptographic 
modules  and  random  number 
generator  if  the  application 
implements  encryption,  key 
exchange,  digital  signature, 
and  hash  functionality. 

Encryption  is  not  used  by  the 
application. 

APP3170 

Medium 

The  designerwill  ensure  the 
application  uses  encryption  to 
implement  key  exchange  and 
authenticate  endpoints  prior 
to  establishing  a 
communication  channel  for 
key  exchange. 

Encryption  is  not  used  by  the 
application. 

APP3210 

Medium 

The  designerwill  ensure  the 
appropriate  cryptography  is 
used  to  protect  stored  DOD 
information  if  required  by  the 
information  owner. 

Encryption  is  not  used  by  the 
application. 

APP3220 

Medium 

The  designerwill  ensure 
sensitive  data  held  in  memory 
is  cryptographically  protected 
when  not  in  use,  if  required 
by  the  information  owner,  and 
classified  data  held  in 
memory  is  always 
cryptographically  protected 
when  not  in  use. 

Encryption  is  not  used  by  the 
application. 
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STIG  ID 
Severity 

Requirement  from  ASD 

STIG 

Finding  Details  from  SCA 

APP3230 

Medium 

The  designerwill  ensure  the 
application  properly  clears  or 
overwrites  all  memory  blocks 
used  to  process  sensitive 
data,  if  required  by  the 
information  owner,  and  clears 
or  overwrites  all  memory 
blocks  used  for  classified 
data. 

Because  of  the  nature  of  MAST,  it  is 
possible  to  load  sensitive  data  into 
memory.  The  application  does  not 
have  the  ability  to  clear  or  overwrite 
memory  blocks  used  to  process 
sensitive  data. 

APP3240 

Medium 

The  designerwill  ensure  all 
access  authorizations  to  data 
are  revoked  prior  to  initial 
assignment,  allocation  or 
reallocation  to  an  unused 
state. 

Design  document  does  not  exist. 

APP3250 

High 

The  designerwill  ensure  data 
transmitted  through  a 
commercial  or  wireless 
network  is  protected  using  an 
appropriate  form  of 
cryptography. 

Encryption  is  not  used  by  the 
application. 

APP3260 

Medium 

The  designerwill  ensure  the 
application  uses  mechanisms 
assuring  the  integrity  of  all 
transmitted  information 
(including  labels  and  security 
parameters). 

Application  does  not  use  any  kind  of 
integrity  mechanism. 

APP3270 

High 

The  designerwill  ensure  the 
application  has  the  capability 
to  mark  sensitive/classified 
output  when  required. 

Application  does  not  have  the  ability 
to  mark  sensitive  or  classified  data. 
Documentation  indicating  howto 
handle  sensitive  or  classified  data  is 
also  absent. 

APP3300 

Medium 

The  designerwill  ensure 
applications  requiring  server 
authentication  are  PK- 
enabled. 

Application  does  not  have  server 
authentication  mechanism.  Lack  of 
capability  is  a  finding.  A  PKI  waiver 
would  be  required  to  continue 
without  being  PKI  enabled. 
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STIG  ID 
Severity 

Requirement  from  ASD 

STIG 

Finding  Details  from  SCA 

APP3450 

Medium 

The  designer  and  IAO  will 
ensure  application  resources 
are  protected  with  permission 
sets  which  allow  only  an 
application  administrator  to 
modify  application  resource 
configuration  files. 

As  a  desktop  application,  the  ability 
to  ensure  application  resources  are 
protected  with  any  permission  sets  is 
not  possible. 

APP3470 

Medium 

The  designerwill  ensure  the 
application  is  organized  by 
functionality  and  roles  to 
support  the  assignment  of 
specific  roles  to  specific 
application  functions. 

Application  does  not  implement  a 
roles  capability  to  organize 
functionality. 

APP3480 

High 

The  designerwill  ensure 
access  control  mechanisms 
exist  to  ensure  data  is 
accessed  and  changed  only 
by  authorized  personnel. 

Application  does  not  deploy  any  kind 
of  access  control,  leaving  its 
features,  capabilities  and  functions 
unprotected. 

APP3500 

Medium 

The  designerwill  ensure  the 
application  executes  with  no 
more  privileges  than 
necessary  for  proper 
operation. 

The  nature  of  this  application 
requires  that  it  have  significantly 
more  permissions  than  the  average 
desktop  application. 

APP3510 

High 

The  designerwill  ensure  the 
application  validates  all  input. 

Application  test  plans  are  not 
available,  indicating  not  all  input 
validation  vulnerabilities  are  tested 
for,  as  required  by  ASD  STIG. 
Additionally,  code  review  sample 
revealed  that  input  is  not  validated|in 
multiple  methods  including: 
ClientProgram.main(), 
NetworkLoader(),NetworkLoader. 
readJSONFromFileO 

APP3550 

High 

The  designerwill  ensure  the 
application  is  not  vulnerable 
to  integer  arithmetic  issues. 

Application  has  numerous  areas  in 
source  code  that  do  not  check  for 
integer  overflows.  Particular 
potential  issues  are  in  the  scenario 
parsing  files,  where  integers  read 
from  a  file  without  validation. 
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STIG  ID 
Severity 

Requirement  from  ASD 

STIG 

Finding  Details  from  SCA 

APP3560 

High 

The  designerwill  ensure  the 
application  does  not  contain 
format  string  vulnerabilities. 

Potential  format  string  vulnerabilities 
exist  in 

mastSEServer.ServerCLI.print(String 
target).  Application  does  not  appear 
to  validate  input, 

APP3570 

High 

The  designerwill  ensure  the 
application  does  not  allow 
command  injection. 

Application  test  plans  are  not 
available,  indicating  command 
injection  vulnerabilities  may  not  be 
tested  for,  as  required  by  ASD  STIG. 
Additionally,  code  review  sample 
revealed  that  the 

ClientProgram.main()  method  lacks 
sufficient  input  validation  in  network 
input  calls  to  inhibit  a  command 
injection  attack. 

APP3590 

High 

The  designerwill  ensure  the 
application  does  not  have 
bufferoverflows,  use 
functions  known  to  be 
vulnerable  to  buffer 
overflows,  and  does  not  use 
signed  values  for  memory 
allocation  where  permitted  by 
the  programming  language. 

Application  test  plans  are  not 
available,  indicating  buffer  overflow 
vulnerabilities  may  not  be  tested  for, 
as  required  by  ASD  STIG. 

Additionally,  code  review  sample 
revealed  that  the 

ScenarioValidator.validate()  method 
reads  multiple  strings  from  a  file  and 
does  not  validate  buffer  sizes 
allowing  for  potential  overflows. 

APP3600 

Medium 

The  designerwill  ensure  the 
application  has  no  canonical 
representation  vulnerabilities. 

Application  test  plans  are  not 
available,  indicating  canonical 
representation  vulnerabilities  may 
not  be  tested  for,  as  required  by 

ASD  STIG. 

Additionally,  code  review  sample 
revealed  that  the  SEServer  class 
has  methods  that  consume  file  paths 
without  protective  measures 
including  pats  to  log  and  scenario 
files. 

APP3620 

Medium 

The  designerwill  ensure  the 
application  does  not  disclose 
unnecessary  information  to 
users. 

Application  has  exceptions  that 
present  stack  traces  to  users  at 
runtime. 
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STIG  ID 
Severity 

Requirement  from  ASD 

STIG 

Finding  Details  from  SCA 

APP3630 

Medium 

The  designerwill  ensure  the 
application  is  not  vulnerable 
to  race  conditions. 

Application  test  plans  are  not 
available,  indicating  race  conditions 
vulnerabilities  are  not  tested  for. 

APP3650 

Low 

The  designerwill  ensure  the 
application  has  a  capability  to 
notify  an  administrator  when 
audit  logs  are  nearing 
capacity  as  specified  in  the 
system  documentation. 

Application  does  notify  an 
administrator  when  audit  logs  are 
nearing  capacity  and  no 
specification  exists  in  system 
documentation. 

APP3670 

Medium 

The  designerwill  ensure  the 
application  has  a  capability  to 
display  the  user’s  time  and 
date  of  the  last  change  in 
data  content. 

Application  does  not  have  the 
capability  to  display  the  user’s  time 
and  date  of  the  last  change  in  data 
content. 

APP3680 

Medium 

The  designerwill  ensure  the 
application  design  includes 
audits  on  all  access  to  need- 
to-know  information  and  key 
application  events. 

Application  does  not  audit  all 
required  fields. 

APP3690 

Medium 

The  designerand  IAO  will 
ensure  the  audit  trail  is 
readable  only  by  the 
application  and  auditors  and 
protected  against  modification 
and  deletion  by  unauthorized 
individuals. 

Application  audit  trail  is  not  protected 
from  modification  and  deletion  by 
unauthorized  individuals. 

APP3700 

Medium 

The  designerwill  ensure 
unsigned  Category  1 A  mobile 
code  is  not  used  in  the 
application  in  accordance 
with  DOD  policy. 

Application’s  Simware  modules 
contain  various  forms  of  mobile 
code,  which  are  unsigned. 

APP3710 

Medium 

The  designerwill  ensure 
signed  Category  1A  and 
Category  2  mobile  code 
signature  is  validated  before 
executing. 

Application  performs  no  validation  of 
mobile  code. 
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STIG  ID 
Severity 

Requirement  from  ASD 

STIG 

Finding  Details  from  SCA 

APP3720 

Medium 

The  designerwill  ensure 
unsigned  Category  2  mobile 
code  executing  in  a 
constrained  environment  has 
no  access  to  local  system 
and  network  resources. 

Category  2  mobile  code  may  be 
required  in  the  Simware  this 
application  deploys,  requiring  that 
this  control  not  be  enforced. 

APP3730 

Medium 

The  designerwill  ensure 
uncategorized  or  emerging 
mobile  code  is  not  used  in 
applications. 

Emerging  mobile  code  can  be 
implemented  depending  on  the 
Simware  deployed  by  the 
application.  Emerging  code  cannot 
be  used  and  should  be  submitted  for 
risk  assessment.  [11] 

APP3750 

Medium 

The  designerwill  ensure 
developmentof  new  mobile 
code  includes  measures  to 
mitigate  the  risks  identified. 

Risk  Mitigation  plans  have  not  been 
developed  for  any  mobile  code  that 
is  deployed.  [11] 

APP3960 

Medium 

The  designerwill  ensure  the 
application  is  compliant  with 
all  DOD  IT  Standards 

Registry  (DISR)  IPv6  profiles. 

Application  is  not  IPv6  capable. 

APP3970 

Medium 

The  designerwill  ensure 
supporting  application 
services  and  interfaces  have 
been  designed,  or  upgraded 
for,  IPv6  transport. 

Application  is  not  IPv6  capable. 

APP3980 

Medium 

The  designerwill  ensure  the 
application  is  compliant  with 
IPv6  multicast  addressing 
and  features  an  IPv6  network 
configuration  options  as 
defined  in  RFC  4038. 

Application  is  not  IPv6  capable. 

APP3990 

Medium 

The  designerwill  ensure  the 
application  is  compliant  with 
the  IPv6  addressing  scheme 
as  defined  in  RFC  1 884. 

Application  is  not  IPv6  capable. 
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E.  SOFTWARE  CONFIGURATION  MANAGEMENT  FINDINGS 

Table  8,  Summary  of  Software  Configuration  Management  Findings, 
provides  a  numeric  summary  of  the  findings  in  software  configuration 
management. 


Table  8.  Summary  of  Software  Configuration  Management  Findings 


Severity 

Not  A  Finding 

Not  Applicable 

Open 

CAT  1 

0 

0 

0 

CAT  II 

0 

0 

3 

CAT  III 

0 

0 

1 

Table  9,  Software  Configuration  Management  Findings  Details,  describes 
specific  findings  in  software  configuration  management.  The  findings  are  non¬ 
technical  in  nature. 
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Table  9.  Software  Configuration  Management  Findings  Details,  after 

[1] 


STIG  ID 
Seventy 

Requirement 

Finding  Details 

APP4010 

Low 

The  Release  Manager  will 
ensure  the  access  privileges 
to  the  configuration 
management  (CM)  repository 
are  reviewed  every  3  months. 

A  Software  Configuration 

Management  program  has  not  been 
developed  for  the  application. 

APP4030 

Medium 

The  Release  Manager  will 
develop  an  SCM  plan 
describing  the  configuration 
control  and  change 
management  process  of 
objects  developed  and  the 
roles  and  responsibilities  of 
the  organization. 

A  Software  Configuration 

Management  program  has  not  been 
developed  for  the  application. 

APP404 

MediumO 

The  Release  Manager  will 
establish  a  Configuration 
Control  Board  (CCB),  which 
meets  at  least  every  release 
cycle,  for  managing  the  CM 
process. 

A  Software  Configuration 

Management  program  has  not  been 
developed  for  the  application. 

APP4050 

Medium 

The  release  manager  must 
ensure  application  files  are 
cryptographically  hashed  prior 
to  deploying  to  DOD 
operational  networks. 

A  Software  Configuration 

Management  program  has  not  been 
developed  for  the  application. 
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F.  TESTING  FINDINGS 

Table  10,  Summary  of  Testing  Findings,  provides  a  numerical  summary  of 
the  findings  in  testing. 


Table  10.  Summary  of  Testing  Findings 


Severity 

Not  A  Finding 

Not  Applicable 

Open 

CAT  1 

0 

0 

0 

CAT  II 

1 

0 

8 

CAT  III 

0 

0 

2 

Table  1 1 ,  Testing  Findings  Details,  describes  specific  findings  testing.  The 
findings  are  non-technical  in  nature. 


Table  1 1 .  Testing  Findings  Details,  after  [1] 


STIG  ID 
Severity 

Requirement 

Finding  Details 

APP2160 

Medium 

The  Program  Manager  and 

IAO  will  ensure  development 
systems,  build  systems,  test 
systems,  and  all  components 
comply  with  all  appropriate 

DOD  STIGs,  NSA  guides,  and 
all  applicable  DOD  policies. 

The  Test  Manager  will  ensure 
both  client  and  server 
machines  are  STIG  compliant. 

Development  on  a  STIG-compliant 
platform  is  not  documented. 

APP5010 

Low 

The  Test  Manager  will  ensure 
at  least  one  tester  is 
designated  to  test  for  security 
flaws  in  addition  to  functional 
testing. 

No  one  is  designated  to  test  the 
application  for  security  flaws 
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STIG  ID 
Severity 

Requirement 

Finding  Details 

APP5040 

Medium 

The  Test  Managerwill  ensure 
the  changes  to  the  application 
are  assessed  for  IA  and 
accreditation  impact  prior  to 
implementation. 

Changes  to  the  application  are  not 
assessed  for  IA  and  accreditation 
impact  prior  to  implementation. 

APP5050 

Medium 

The  Test  Managerwill  ensure 
tests  plans  and  procedures 
are  created  and  executed 
prior  to  each  release  of  the 
application  or  updates  to 
system  patches. 

Test  plans,  procedures,  and  results 
do  not  exist. 

APP5060 

Medium 

The  Test  Managerwill  ensure 
test  procedures  are  created 
and  at  least  annually 
executed  to  ensure  system 
initialization,  shutdown,  and 
aborts  are  configured  to 
ensure  the  system  remains  in 
a  secure  state. 

Test  plans,  procedures,  and  results 
do  not  exist. 

APP5070 

Low 

The  Test  Managerwill  ensure 
code  coverage  statistics  are 
maintained  for  each  release  of 
the  application. 

Code  coverage  statistics  are  not 
maintained. 

APP5080 

Medium 

The  Test  Managerwill  ensure 
a  code  review  is  performed 
before  the  application  is 
released. 

Application  code  is  not  being 
reviewed. 

APP5090 

Medium 

The  Test  Managerwill  ensure 
flaws  found  during  a  code 
review  are  tracked  in  a  defect 
tracking  system. 

Application  code  is  not  being 
reviewed. 

APP5100 

Medium 

The  IAO  will  ensure  active 
vulnerability  testing  is 
performed. 

Vulnerability  testing  is  not  performed. 

APP5110 

Medium 

The  Test  Managerwill  ensure 
security  flaws  are  fixed  or 
addressed  in  the  project  plan. 

The  application  does  not  have  a 
project  plan. 
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G.  DEPLOYMENT  FINDINGS 

Table  12,  Summary  of  Deployment  Findings,  provides  a  numerical 
summary  of  the  findings  in  deployment. 


Table  12.  Summary  of  Deployment  Findings 


Severity 

Not  A  Finding 

Not  Applicable 

Open 

CAT  1 

0 

4 

0 

CAT  II 

1 

14 

23 

CAT  III 

1 

2 

2 

Table  13,  Deployment  Findings  Details,  describes  the  specific  findings  of 
deployment.  These  findings  typically  apply  to  applications  later  in  their  life  cycle 
than  MAST;  however,  many  still  do  apply. 
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Table  13.  Deployment  Findings  Details,  after  [1] 


STIG  ID 
Severity 

Requirement 

Finding  Details 

APP2010 

Medium 

The  Program  Managerwill 
ensure  a  System  Security 

Plan  (SSP)  is  established  to 
describe  the  technical, 
administrative,  and  procedural 
IA  program  and  policies 
governing  the  DOD 
information  system,  and 
identifying  all  IA  personnel 
and  specific  IA  requirements 
and  objectives. 

Application  does  not  have  a  system 
security  plan  (SSP). 

APP2020 

Medium 

The  Program  Managerwill 
provide  an  Application 
Configuration  Guide  to  the 
application  hosting  providers 
to  include  a  list  of  all  potential 
hosting  enclaves  and 
connection  rules  and 
requirements. 

Application  does  not  have  an 
Application  Configuration  Guide. 

APP2040 

Medium 

If  the  application  contains 
classified  data,  the  Program 
Managerwill  ensure  a 

Security  Classification  Guide 
exists  containing  data 
elements  and  their 
classification. 

Because  MAST  could  be  installed 
on  a  classified  system,  requires 
Security  Classification  Guide  in 
order  to  manage  any  outputs  from 
the  tool. 

APP2100 

Medium 

The  Program  Manager  and 
designerwill  ensure  the 
application  design  complies 
with  the  DOD  Ports  and 
Protocols  guidance. 

DOD  Ports,  Protocols,  and  Services 
(PPS)  Vulnerability  Analysis 
compliance  has  not  yet  been 
determined.  Also,  a  new  protocol  is 
being  deployed  to  operate  the 
application  and  must  be  submitted  to 
DOD  for  risk  assessment.  [1 0], 

APP2110 

Medium 

The  Program  Managerand 
designerwill  ensure  the 
application  is  registered  with 
the  DOD  Ports  and  Protocols 
Database. 

Application  registration  in  the  DOD 
Ports  and  Protocols  Database  has 
not  yet  been  completed. 
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STIG  ID 
Severity 

Requirement 

Finding  Details 

APP2140 

Medium 

The  Program  Managerwill 
ensure  a  security  incident 
response  process  for  the 
application  is  established  that 
defines  reportable  incidents 
and  outlines  a  standard 
operating  procedure  for 
incident  response  to  include 
Information  Operations 
Condition  (INFOCON). 

A  security  incident  response  process 
is  not  documented. 

APP2150 

Medium 

The  Program  Managerwill 
ensure  procedures  are 
implemented  to  assure 
physical  handling  and  storage 
of  information  is  in 
accordance  with  the  data’s 
sensitivity. 

Procedures  assure  physical 
handling  and  storage  of  information 
is  in  accordance  with  the  data's 
sensitivity  are  not  documented. 

APP2160 

Medium 

The  Program  Manager  and 

IAO  will  ensure  development 
systems,  build  systems,  test 
systems,  and  all  components 
comply  with  all  appropriate 

DOD  STIGs,  NSA  guides,  and 
all  applicable  DOD  policies. 

The  Test  Managerwill  ensure 
both  client  and  server 
machines  are  STIG  compliant. 

Development  on  a  STIG  compliant 
platform  is  not  documented. 

APP3020 

Medium 

The  designerwill  ensure 
threat  models  are 
documented  and  reviewed  for 
each  application  release  and 
updated  as  required  by  design 
and  functionality  changes  or 
new  threats  are  discovered. 

A  threat  model  was  not  developed 
for  the  application. 
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STIG  ID 
Severity 

Requirement 

Finding  Details 

APP3450 

Medium 

The  designer  and  IAO  will 
ensure  application  resources 
are  protected  with  permission 
sets  which  allow  only  an 
application  administrator  to 
modify  application  resource 
configuration  files. 

As  a  desktop  application,  the  ability 
to  ensure  application  resources  are 
protected  with  any  permission  sets 
is  not  possible. 

APP3470 

Medium 

The  designerwill  ensure  the 
application  is  organized  by 
functionality  and  roles  to 
support  the  assignment  of 
specific  roles  to  specific 
application  functions. 

Application  does  not  implement  a 
roles  capability. 

APP3690 

Medium 

The  designer  and  IAO  will 
ensure  the  audit  trail  is 
readable  only  by  the 
application  and  auditors  and 
protected  against  modification 
and  deletion  by  unauthorized 
individuals. 

Application  audit  trail  is  not 
protected  from  modification  and 
deletion  by  unauthorized  individuals. 

APP6010 

Medium 

The  IAO  will  ensure  if  an 
application  is  designated 
critical,  the  application  is  not 
hosted  on  a  general  purpose 
machine. 

The  nature  of  MAST  requires  that  it 
be  co-hosted  with  whatever 
applications  reside  on  the  platform 
that  it  will  operate  on.  This  risk  must 
be  accepted. 

APP6030 

Medium 

The  IAO  will  ensure 
unnecessary  services  are 
disabled  or  removed. 

No  unnecessary  services  are 
enabled  forthe  application. 

APP6040 

Medium 

The  IAO  will  ensure  at  least 
one  application  administrator 
has  registered  to  receive 
update  notifications,  or 
security  alerts,  when 
automated  alerts  are 
available. 

Update  notifications  are  not 
available  forthe  application. 
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STIG  ID 
Severity 

Requirement 

Finding  Details 

APP6050 

Medium 

The  IAO  will  ensure  the 
system  and  installed 
applications  have  current 
patches,  security  updates, 
and  configuration  settings. 

A  configuration  managementplan, 
including  procedures,  does  not  exist. 

APP6060 

High 

The  IAO  will  ensure  the 
application  is 
decommissioned  when 
maintenance  or  support  is  no 
longer  available. 

Application  is  not  yet  under 
maintenance. 

APP6080 

Medium 

The  IAO  will  ensure 
protections  against  DoS 
attacks  are  implemented. 

Application  does  not  have  a  threat 
model. 

APP6110 

Low 

The  IAO  will  review  audit  trails 
periodically  based  on  system 
documentation 
recommendations  or 
immediately  upon  system 
security  events. 

Application  does  not  audit  all 
required  fields  to  make  periodic 
review  an  effective  control. 

APP6130 

Low 

The  IAO  will  ensure,  for 
classified  systems,  application 
audit  trails  are  continuously 
and  automatically  monitored, 
and  alerts  are  provided 
immediately  when  unusualor 
inappropriate  activity  is 
detected. 

System’s  confidentiality  level  has  not 
yet  been  assigned,  which  prevents 
completion  of  this  assessment. 
Because  the  possibility  exists  that  it 
may  operate  in  a  classified 
environment,  this  must  remain  an 
open  finding. 

APP6140 

Medium 

The  IAO  will  ensure 
application  audit  trails  are 
retained  for  at  least  1  year  for 
applications  without  SAMI 
data,  and  5  years  for 
applications  including  SAMI 
data. 

Application  does  not  maintain  log 
entries  for  intervals  of  that  length. 
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STIG  ID 
Severity 

Requirement 

Finding  Details 

APP6160 

Medium 

The  IAO  will  ensure  recovery 
procedures  and  technical 
system  features  exist  so 
recovery  is  performed  in  a 
secure  and  verifiable  manner. 
The  IAO  will  document 
circumstances  inhibiting  a 
trusted  recovery. 

Application  does  not  have  a  disaster 
recovery  plan. 

APP6170 

Medium 

The  IAO  will  ensure  back-up 
copies  of  the  application 
software  are  stored  in  a  fire¬ 
rated  container  and  not 
collocated  with  operational 
software. 

No  documentation  on  data  backups 
was  available. 

APP6180 

Medium 

The  IAO  will  ensure 
procedures  are  in  place  to 
assure  the  appropriate 
physical  and  technical 
protection  of  the  backup  and 
restoration  of  the  application. 

No  documentation  on  data  backups 
was  available. 

APP6190 

Medium 

The  IAO  will  ensure  data 
backup  is  performed  at 
required  intervals  in 
accordance  with  DOD  policy. 

No  documentation  on  data  backups 
was  available.  Application  likely 
does  not  require  backups,  however 
there  is  no  documentation  to  state 

so. 

APP6200 

Medium 

The  IAO  will  ensure  a  disaster 
recovery  plan  exists  in 
accordance  with  DOD  policy 
based  on  the  Mission 
Assurance  Category  (MAC). 

Application  does  not  have  a  disaster 
recovery  plan  and  also  does  not 
have  a  Mission  Assurance  Category 
(MAC)  assigned  to  drive  that  plan’s 
creation. 
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H.  SUMMARY 


In  this  chapter,  the  results  of  the  SCA  of  MAST  were  enumerated.  As 
documented  in  Table  3.  Overall  Summary  of  Findings,  MAST  had  9  CAT  I,  62 
CAT  II,  and  6  CAT  III  findings.  Typically  CAT  III  findings  are  overlooked  in  DoN 
SCA  practice.  The  CAT  I  and  CAT  II  findings,  however,  require  mitigation  efforts. 
Chapter  V  documents  a  threat  model  approach  to  the  address  the  most 
dangerous  vulnerabilities  in  MAST. 
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V.  MITIGATION  AND  REMEDIATION  THROUGH  THREAT 

MODELING 


This  chapter  describes  architecture  changes  and  vulnerability  mitigations 
to  improve  MAST’s  overall  security  posture. 

In  order  to  deploy  effective  vulnerability  mitigations  to  an  application  its 
threat  model  must  be  understood.  A  threat  model  is  a  representation  of  threats  to 
an  application,  prioritization  those  threats,  and  application  of  countermeasures 
and  mitigations.  A  threat  model  must  be  conducted  early  in  an  application 
development  life  cycle. 

For  MAST,  or  any  DOD  system,  some  threat  modeling  burden  is  relieved 
via  the  application  and  implementation  of  DISA  STIGs.  The  STIGs  are  designed 
to  address  vulnerabilities  commonly  found  in  “the  wild.”  For  example,  according 
to  [12],  the  top  application  vulnerability  is  injection  flaws  such  as  SQL  injections 
attacks  for  web  applications.  To  address  this  common  weakness,  [1]  has  multiple 
checks  for  input  validation  and  injection  attack  defense.  Despite  this  “pre¬ 
completed”  modeling. 

For  the  purpose  of  this  research  a  threat  model  is  created  and  analyzed 
under  the  context  of  improving  MAST’s  security  posture.  Unlike  typical  threat 
models  which  are  intended  to  occur  as  part  of  the  design  process,  this  threat 
model  will  be  used  to  funnel  security  posture  improvement  effort  into  major  areas 
of  concern.  Again,  as  the  research  is  conducted  outside  of  MAST’s  development 
process,  some  tailoring  liberty  is  required  to  model  after  the  fact;  such  tailoring 
will  be  explained  as  needed.  Also,  the  intent  is  not  to  include  detailed  tutorial  on 
threat  modeling  but  rather  utilize  existing  techniques,  as  such  general  detail  on 
how  to  build  a  threat  model  should  be  sought  through  other  resources. 
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A.  THREAT  MODEL  BASICS 

According  to  [13],  there  are  nine  steps  to  developing  a  security  model: 

1 .  Define  use  scenarios 

2.  List  external  dependencies 

3.  Define  security  assumptions 

4.  Create  external  security  notes 

5.  Create  data  flow  diagrams  (DFD) 

6.  Determine  threat  types 

7.  Identify  threats  to  the  system 

8.  Determine  risk 

9.  Plan  mitigations 

The  following  sections  establish  the  threat  model  for  MAST. 

B.  MAST  USE  SCENARIOS 

A  Use  Scenario  describes  how  the  subject  of  a  threat  model  is  used. 

As  discussed  in  Chapter  II,  MAST  is  a  desktop  application  designed  to 
simulate  malware  on  operational  platforms.  It  consists  of  three  desktop 
application  components  in  a  three-tier  architecture  in  which  modules  called 
Simware  and  Scenario  files  are  passed  between  the  tiers  to  execute  simulations. 

C.  MAST  EXTERNAL  DEPENDENCIES 

External  dependencies  in  the  context  of  threat  models  are  other  pieces  of 
software  and  hardware  that  are  not  within  the  scope  of  the  software  being 
modeled  but  may  have  an  impact  on  what  threats  it  will  face. 
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As  MAST  is  designed  to  be  deployed  to  operational  platforms  its  external 
dependencies  vary  wildly.  Some  predictable  expectations  include: 

•  Installation  on  a  Microsoft  Windows  operating  system 

•  Dependency  on  the  Java  virtual  machine  to  run 

•  Networking  support 

D.  MAST  SECURITY  ASSUMPTIONS 

Security  assumptions  are  prerequisites  and  expectations  the  software 
being  modeled  may  have  for  it  dependencies  and  environment,  particularly  in  the 
support  of  security.  Examples  might  include  encryption  services  and  file 
permissions  implemented  by  a  hosting  operating  system. 

In  the  case  of  MAST,  no  security  assumptions  can  be  made  based  on  the 
documentation  available  at  the  time  of  this  research. 

E.  MAST  DATA  FLOW  DIAGRAMS 

DFDs  demonstrate  how  the  application  interacts  with  its  own  components 
and  external  interfaces. 

Several  DFDs  are  required  to  describe  MAST.  DFD  elements  are 
numbered  to  facilitate  discussion. 

Figure  2,  MAST  DFD  with  MAST  Components,  shows  how  the  various 
components  of  MAST  interact  for  command  and  control  (C2).  This  data  flow 
demonstrates  how  the  various  tiers  of  MAST  communicate.  To  meet  the  needs  of 
this  exercise,  only  “Request”  and  “Response”  transaction  need  be  modeled.  In 
this  DFD,  a  request  is  an  instruction  from  one  tier  of  MAST  to  a  lower  tier.  The 
response  represents  some  acknowledgement  from  the  lower  tier  to  the  higher 
tier. 
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Figure  2.  MAST  DFD  with  MAST  Components 


Figure  3,  MAST  Simware  and  Scenario  File  Distribution,  shows  how 
MAST  Simware  and  Scenario  files  are  passed  from  the  MAST  SG  Server  to  the 
MAST  Scenario  ES  through  to  the  MAST  Client. 
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Figure  3.  MAST  Simware  and  Scenario  File  Distribution 
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Figure  4,  MAST  DFD  with  User,  shows  user  interaction  with  the  MAST  SG 
Sever  and  MAST  SE  Server  however  due  to  MAST  being  a  desktop  application; 
this  particular  DFD  will  not  be  used.  It  is  only  provided  for  completion. 

Each  DFD’s  items  are  numbered  to  facilitate  discussion  throughout  the 
threat  model.  When  an  item  appears  in  multiple  models  its  number  assignment  is 
consistent. 

F.  MAST  THREAT  TYPES 

This  stage  of  threat  modeling  determines  how  to  categorize  threat  types. 
This  categorization  is  crucial  for  the  next  step  of  the  model.  The  simplest 
approach  utilizes  the  threats  to  confidentiality,  integrity,  and  availability  where 
threats  are  categorized  by  their  impact  to  those  classic  security  pillars.  This  is  the 
approach  that  is  used  in  this  research.  Threat  type  definitions  are  as  follows: 
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•  Confidentiality  Threats — Threats  that  allow  for  information 
disclosure  and  access  to  unauthorized  parties 

•  Integrity  Threats — Threats  that  allow  for  modification  of  data  by 
unauthorized  entities  or  in  an  unauthorized  manner 

•  Availability  Threats — Threats  that  affect  the  accessibility  of 
authorized  entities 

G.  IDENTIFY  THREATS  TO  MAST 

Threat  identification  consists  of  mapping  of  the  established  threat  types  to 
elements  or  data  flows  between  elements.  Table  14,  DFD  Item  Inventory,  lists 
each  item  in  the  DFDs.  The  “Boundary  Gap”  DFD  Elements  Type  is  a  unique 
type  used  for  the  purpose  of  MAST  threat  model.  It  acts  as  a  place  holder  for 
whenever  data  flowed  outside  the  application  boundary.  Its  significance  will  be 
discussed  later  in  the  paper. 


Table  14.  DFD  Item  Inventory 


DFD  Elements  Types 

DFD  Item  Numbers 

External  Entities 

User  (10) 

Processes 

SG  Server  (1) 

SE  Server  (2) 

MAST  Client  (3) 

Simware  (4) 

Data  Flows 

SG  to  SE  Request  (1— >2) 

SE  to  SG  Response  (2— >1 ) 

SE  to  Client  Request  (2->3) 

Client  to  SE  Response  (3->2) 

Client  to  Simware  Request  (3— >4) 

Simware  to  Client  Response  (4— >3) 

SG  to  SE  Simware/Scenario  Download  (1— >2) 

SE  to  Client  Simware/Scenario  Download  (2->3) 
User  to  SG  Request  (10— >1) 

SG  to  User  Response  (1— >10) 

User  to  SE  Request  (10— >2) 

SE  to  User  Response  (2 — >1 0) 

Boundary  GAP 

Trust  Boundary  Gap  (5) 

Trust  Boundary  Gap  (6) 
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In  order  to  simplify  and  reduce  the  redundancy  and  complexity  of  the 
model,  similar  data  paths  can  be  collapsed  as  a  single  dataflow.  Table  15, 
Reduced  DFD  Item  Inventory,  shows  an  inventory  where  common  data  flows  are 
simplified. 


Table  15.  Reduced  DFD  Item  Inventory 


DFD  Elements  Types 

DFD  Item  Numbers 

External  Entities 

User  (10) 

Processes 

SG  Server  (1) 

SE  Server  (2) 

MAST  Client  (3) 

Simware  (4) 

Data  Flows 

SG  to  SE  C2  (1— >2) 

SE  to  Client  C2  (2->3) 

Client  to  Simware  C2  (3— >4) 

SG  to  SE  Simware/Scenario  Download  (1— >2) 

SE  to  Client  Simware/Scenario  Download  (2— >-3) 

Boundary  GAP 

Trust  Boundary  Gap  (5) 

Trust  Boundary  Gap  (6) 

Table  16,  Threats  to  MAST,  shows  a  simplified  listing  of  the  threats  that 
MAST  must  defend  against. 


Table  16.  Threats  to  MAST 


Threat  Type 

Effected  DFD  Item 

Confidentiality 

SG  to  SE  C2  and  Downloads  (1— >2) 

SE  to  Client  C2  and  Downloads  (2->3) 

Integrity 

SG  to  SE  C2  and  Downloads  (1-»2) 

SE  to  Client  C2  and  Downloads  (2— >3) 

Simware  (4) 

Availability 

N/a 
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H.  DETERMINE  RISK  TO  MAST 


Once  threats  have  been  established,  the  risk  those  threats  pose  to  the 
subject  system  must  be  determined.  This  helps  prioritize  resources  to  remediate 
and  mitigate  vulnerabilities. 

There  are  many  methodologies  available  to  assess  risk  of  a  threat.  To 
keep  aligned  with  this  research’s  DOD  SCA  focus,  severities  from  [1]  are  used  to 
assess  the  risk  of  vulnerabilities. 

The  Confidentiality  threat  risk  is  established  in  the  following  controls  from 
[1]  where  the  SCA  generated  findings: 

•  APP3250— High  Risk 

•  APP3330— High  Risk 

•  APP3340— High  Risk 

•  APP3405— High  Risk 

•  APP3210 — Medium  Risk 

•  APP3260 — Medium  Risk 

•  APP3150 — Medium  Risk 

•  APP3170 — Medium  Risk 

•  APP3220 — Medium  Risk 

•  APP3900 — Medium  Risk 

•  APP3950 — Medium  Risk 

•  APP2070 — Low  Risk 

In  accordance  with  DOD  risk  management  practice  the  highest  risk  rating 
of  any  particular  control  becomes  the  risk  rating  of  any  group  controls  of  which  it 
is  a  part.  In  this  risk  model,  Confidentiality  related  controls  were  grouped 
together.  Because  several  controls  are  high  risk  per  [1],  the  overall  risk  of  the 
group  is  high  risk 
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The  Integrity  threat  risk  is  established  in  the  following  controls  from  [1] 
where  the  SCA  generated  findings: 

•  APP3700 — Medium  Risk 

•  APP3710 — Medium  Risk 

•  APP3720 — Medium  Risk 

•  APP3730 — Medium  Risk 

•  APP3740 — Medium  Risk 

•  APP3750 — Medium  Risk 

These  STIG  severities  require  that  these  risks  be  assessed  as  medium 
risk.  As  in  the  Confidentiality  section,  Integrity  related  controls  were  grouped 
together  in  the  risk  model,  and  the  highest  risk  assessed  to  any  of  the  controls  is 
medium.  Thus,  the  overall  risk  of  the  Integrity  group  is  medium 

Due  to  the  sensitive  nature  of  MASTs  purpose,  simulating  malware  on 
operational  platforms,  thereby  reducing  the  risk  beyond  the  severity  in  [1]  without 
taking  technical  measure  to  actually  closing  the  finding  is  inappropriate. 

I.  PLAN  MITIGATIONS  FOR  MAST 

Once  risks  have  been  prioritized  and  measured,  mitigation  should  follow. 
Risk  response  typically  has  several  different  approaches  and  these  approaches 
can  be  mixed  and  blended  to  serve  the  purpose  of  the  program  or  organization. 
As  defined  in  [14],  these  approaches  are: 

•  Risk  Acceptance — This  risk  response  approach  occurs  when  a 
program  or  organization  tolerates  the  risk  as  assessed  and  takes 
no  measures  to  change  the  risk  as  it  is  assessed. 

•  Risk  Avoidance — This  risk  response  approach  is  the  result  of  a 
program  or  organization  halting  the  activity  or  endeavor  that  causes 
the  risk  to  be  generated  in  the  first  place. 

•  Risk  Mitigation — This  risk  response  approach  is  due  to  the  program 
or  organization  taking  measures  to  reduce  the  risk  or  otherwise 
alter  the  risk  as  it  is  assessed. 
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•  Risk  Sharing  or  Transfer — This  risk  response  approach  is  selected 
when  the  program  or  organization  uses  a  third  party  to  absorb 
some  or  all  of  the  risk  as  assessed.  Typically  this  strategy  is  related 
to  insurance. 

Changes  to  system  architecture  and  other  technical  improvements  to  an 
IS  are  considered  risk  mitigations.  Thus,  for  the  purpose  of  this  research,  only 
mitigations  to  risk  will  be  discussed. 

(1)  Application  Tier-to-Tier  Trust 

MAST  is  designed  as  a  three-tiered  application  with  each  tier  having  a 
network  stack  and  capability  of  being  placed  on  separate  hosts.  This  separation 
injects  “trust  boundaries”  outside  of  which  MAST  cannot  guarantee  the 
confidentiality  and  integrity  of  the  communications  between  its  components. 

In  order  to  meet  the  confidentiality  and  integrity  needs,  encryption  needs 
to  be  deployed.  MAST  uses  the  java.net  library  for  communication  between  its 
three  tiers;  specifically  the  Socket  and  ServerSocket  classes  are  used.  This  is,  of 
course,  the  unencrypted  socket  library.  The  Java  language  has  an  SSL  library, 
javax.net. ssl,  with  SSLSocket  and  SSLServerSocket  classes  [15].  These  libraries 
can  very  rapidly  provide  for  the  encryption  and  in  turn  confidentiality  and  integrity 
needs  of  MAST. 

In  addition  to  encryption,  an  authentication  scheme  must  be  deployed  to 
ensure  clients  and  servers  within  MAST  communicate  with  only  the  entities  that 
are  intended.  There  is  no  simple  solution  here.  MAST  would  need  to  undergo  a 
significant  change  to  support  an  authentication  scheme.  As  MAST  is  designed  to 
run  on  an  operational  platform  with  built  in  communication  capabilities,  it  may  be 
designed  to  utilize  a  symmetric  encryption  and  inherit  public  key  infrastructure 
(PKI)  capabilities  for  key  and  password  distribution. 

(2)  Simware  Trust 

Simware  are  the  core  of  the  MAST  architecture.  These  modules  perform 
the  actual  simulation  of  malicious  activity.  MAST  Clients  execute  Simware  with 
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no  validation  of  source  or  capabilities  of  module.  There  is  little  to  stop  MAST  from 
being  a  botnet  vice  a  learning  tool  due  to  the  absence  of  these  validation 
capabilities.  Code  signing  and  validation  technologies  could  be  used  to  mitigate 
this  finding. 

J.  THREAT  MODEL  LIMITATIONS 

Threat  models  will  only  directly  model  threats  of  a  technical  nature.  Issues 
related  to  Program  Management,  Configuration  Management,  and  early  design 
decisions  and  related  rigor  will  not  be  apparent  unless  subjected  to  a  SCA  or 
similar  audit.  Many  of  the  findings  discovered  in  the  SCA  are  attributable  to 
nontechnical  issues,  thus  mitigations  in  this  area  are  relatively  simple  as  MAST  is 
so  early  in  its  development  life  cycle. 

Table  17,  Mitigations  Not  Found  in  Threat  Model,  provides  overview  of 
findings  that  would  not  be  apparent  in  a  threat  model  and  also  proposes 
mitigations  to  those  findings. 


Table  17.  Mitigations  Not  Found  in  Threat  Model,  after  [1] 


STIG  ID 
Severity 

Requirement  from  ASD 
STIG 

Mitigation 

APP2010 

Medium 

The  Program  Manager  will 
ensure  a  System  Security 

Plan  (SSP)  is  established  to 
describe  the  technical, 
administrative,  and 
procedural  IA  program  and 
policies  governing  the  DOD 
information  system,  and 
identifying  all  IA  personnel 
and  specific  IA  requirements 
and  objectives. 

Develop  a  System  Security  Plan 
(SSP)  that  addresses 
implementation  of  all  IA  controls  and 
supporting  polices  and  processes  for 
MAST. 
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STIG  ID 
Severity 

Requirement  from  ASD 
STIG 

Mitigation 

APP2020 

Medium 

The  Program  Manager  will 
provide  an  Application 
Configuration  Guide  to  the 
application  hosting  providers 
to  include  a  list  of  all 
potential  hosting  enclaves 
and  connection  rules  and 
requirements. 

Develop  a  Application  Configuration 
Guide  that  describes  how  to  deploy 
MAST  to  a  target  system  or  host. 

APP2040 

Medium 

If  the  application  contains 
classified  data,  the  Program 
Manager  will  ensure  a 

Security  Classification  Guide 
exists  containing  data 
elements  and  their 
classification. 

Develop  a  Security  Classification 
Guide  describing  data  elements 
within  MAST  and  their  classifications 
if  any. 

APP2050 

Medium 

The  Program  Manager  will 
ensure  the  system  has  been 
assigned  specific  MAC  and 
confidentiality  levels. 

Assign  a  MAC  and  confidentiality 
levels  for  MAST. 

APP2060 

Medium 

The  Program  Manager  will 
ensure  the  development 
team  follows  a  set  of  coding 
standards. 

Establish  coding  standards  for  the 
MAST  development  team 

APP2100 

Medium 

The  Program  Manager  and 
designer  will  ensure  the 
application  design  complies 
with  the  DOD  Ports  and 
Protocols  guidance. 

Design  MAST  to  comply  with  DOD 
Ports  and  Protocols  guidance.  This 
will  include  proper  registration  of 
MAST  protocols  DOD  Ports  and 
Protocols  Database. 

APP2110 

Medium 

The  Program  Manager  and 
designer  will  ensure  the 
application  is  registered  with 
the  DOD  Ports  and  Protocols 
Database. 

Design  MAST  to  comply  with  DOD 
Ports  and  Protocols  guidance.  This 
will  include  proper  registration  of 
MAST  protocols  DOD  Ports  and 
Protocols  Database. 

APP2120 

Medium 

The  Program  Manager  will 
ensure  all  levels  of  program 
management,  designers, 
developers,  and  testers 
receive  the  appropriate 
security  training  pertaining  to 
their  job  function. 

Ensure  all  personnel  supporting 

MAST  receive  at  a  minimum  security 
awareness  training.  Additional 
training  might  include  secure 
software  development  and  secure 
coding  curriculum 
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STIG  ID 
Severity 

Requirement  from  ASD 
STIG 

Mitigation 

APP2130 

Medium 

The  Program  Manager  will 
ensure  a  vulnerability 
management  process  is  in 
place  to  include  ensuring  a 
mechanism  is  in  place  to 
notify  users,  and  users  are 
provided  with  a  means  of 
obtaining  security  updates 
for  the  application. 

Develop  a  vulnerability  management 
process  such  that  MAST  users  are 
notified  of  updates  and  have  a 
means  go  acquiring  updates. 

APP2140 

Medium 

The  Program  Manager  will 
ensure  a  security  incident 
response  process  for  the 
application  is  established 
that  defines  reportable 
incidents  and  outlines  a 
standard  operating 
procedure  for  incident 
response  to  include 
Information  Operations 
Condition  (INFOCON). 

Develop  an  incident  response 
process  for  MAST  that  outlines  and 
to  resolve  and  report  incidents  that 
affect  the  application. 

APP2150 

Medium 

The  Program  Manager  will 
ensure  procedures  are 
implemented  to  assure 
physical  handling  and 
storage  of  information  is  in 
accordance  with  the  data’s 
sensitivity. 

Develop  procedures  for  secure 
handling  of  MAST  physical  media. 

APP2160 

Medium 

The  Program  Manager  and 
IAO  will  ensure  development 
systems,  build  systems,  test 
systems,  and  all  components 
comply  with  all  appropriate 
DOD  STIGs,  NSA  guides, 
and  all  applicable  DOD 
policies.  The  Test  Manager 
will  ensure  both  client  and 
server  machines  are  STIG 
compliant. 

Configure  MAST  development  and 
testing  environments  to  meet  and 
comply  with  all  appropriate  DOD 
STIGs,  NSA  guides,  and  all 
applicable  DOD  policies. 

APP3010 

Medium 

The  designer  will  create  and 
update  the  Design  Document 
for  each  release  of  the 
application. 

Develop  and  execute  processes  that 
keep  application  design 
documentation  update  with  each 
release. 
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STIG  ID 
Severity 

Requirement  from  ASD 
STIG 

Mitigation 

APP3020 

Medium 

The  designer  will  ensure 
threat  models  are 
documented  and  reviewed 
for  each  application  release 
and  updated  as  required  by 
design  and  functionality 
changes  or  new  threats  are 
discovered. 

Develop  threat  models  to  properly 
represent  the  threats  that  face 

MAST.  The  model  built  for  this 
research  is  a  starting  point  for  this 
requirement. 

APP3100 

Medium 

The  Designer  will  ensure  the 
application  removes 
temporary  storage  of  files 
and  cookies  when  the 
application  is  terminated. 

Design  MAST  to  remove  any 
temporary  files  that  it  may  create. 

This  would  include  removal  of 
Simware  files  that  are  downloaded 
to  clients  during  routine  MAST  use. 

APP3230 

Medium 

The  designer  will  ensure  the 
application  properly  clears  or 
overwrites  all  memory  blocks 
used  to  process  sensitive 
data,  if  required  by  the 
information  owner,  and 
clears  or  overwrites  all 
memory  blocks  used  for 
classified  data. 

Design  MAST  to  overwrite  any 
memory  it  utilizes.  Because  MAST 
has  the  potential  to  gleam  sensitive 
information  as  it  runs  its  simulations, 
it  must  clean  up  and  reference  to 
that  information  within  its  own 
boundary. 

APP3240 

Medium 

The  designer  will  ensure  all 
access  authorizations  to  data 
are  revoked  prior  to  initial 
assignment,  allocation  or 
reallocation  to  an  unused 
state. 

MAST  has  no  authorization  or 
authentication  process,  making 
compliance  with  this  requirement 
impossible.  Ensure  design  of  a 
subsequent  authorization  or 
authentication  process  revokes 
access  authorizations. 

APP3270 

High 

The  designer  will  ensure  the 
application  has  the  capability 
to  mark  sensitive/classified 
output  when  required. 

MAST  has  no  Security  Classification 
Guide  and  no  indicator  for  what 
confidentiality  it  will  operate  at,  thus 
it  cannot  meet  the  capability  to  mark 
sensitive/classified  output  when 
required.  Satisfy  the  Security 
Classification  Guide  and 
confidentiality  assignment  to  meet 
this  requirement. 

APP3300 

Medium 

The  designer  will  ensure 
applications  requiring  server 
authentication  are  PK- 
enabled. 

MAST  is  likely  not  a  likely  candidate 
for  PKI  enablement  and  as  such,  a 

PKI  waiver  should  be  pursued 
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STIG  ID 
Severity 

Requirement  from  ASD 
STIG 

Mitigation 

APP3450 

Medium 

The  designer  and  IAO  will 
ensure  application  resources 
are  protected  with 
permission  sets  which  allow 
only  an  application 
administrator  to  modify 
application  resource 
configuration  files. 

MAST,  as  a  desktop  application, 
likely  does  not  need  to  provide  any 
additional  protection  to  its  resources 
beyond  what  is  already  provided  by 
its  host.  Including  configuration  for 
this  in  the  Application  Configuration 
Guide  would  resolve  this  finding. 

APP3470 

Medium 

The  designer  will  ensure  the 
application  is  organized  by 
functionality  and  roles  to 
support  the  assignment  of 
specific  roles  to  specific 
application  functions. 

MAST,  as  a  desktop  application, 
likely  does  not  need  to  support  this 
functionality.  Including  configuration 
for  roles  in  the  application 
configuration  guide  would  resolve 
this  finding. 

APP3480 

High 

The  designer  will  ensure 
access  control  mechanisms 
exist  to  ensure  data  is 
accessed  and  changed  only 
by  authorized  personnel. 

MAST,  as  a  desktop  application, 
likely  does  not  need  to  support  this 
functionality.  Including  configuration 
for  access  control  mechanisms  in 
the  application  configuration  guide 
would  resolve  this  finding. 

APP3500 

Medium 

The  designer  will  ensure  the 
application  executes  with  no 
more  privileges  than 
necessary  for  proper 
operation. 

MAST’s  application  configuration 
guide  must  document  that  it 
executes  with  no  more  privileges 
than  necessary  for  proper  operation. 
Actual  installation  must  support  this 
as  well.  Because  MAST  will  emulate 
and  simulate  threatening  behavior 
by  design,  it  will  need  advanced 
privileged  access  on  the  hosts  it  is 
deployed.  This  must  be  documented 
and  understood  clearly. 

APP3510 

High 

The  designer  will  ensure  the 
application  validates  all 
input. 

All  MAST  input  fields  must  validate 
input.  Code  review  processes  can 
find  these  issues  and  also 
demonstrate  their  resolution.  Test 
plans  must  be  developed,  executed, 
and  include  tests  for  this  kind  of 
vulnerability. 
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STIG  ID 
Severity 

Requirement  from  ASD 
STIG 

Mitigation 

APP3550 

High 

The  designer  will  ensure  the 
application  is  not  vulnerable 
to  integer  arithmetic  issues. 

All  MAST  input  fields  must  validate 
input.  Code  review  processes  can 
find  these  issues  and  also 
demonstrate  their  resolution.  Test 
plans  must  be  developed,  executed, 
and  include  tests  for  this  kind  of 
vulnerability. 

APP3560 

High 

The  designer  will  ensure  the 
application  does  not  contain 
format  string  vulnerabilities. 

All  MAST  input  fields  must  validate 
input.  Code  review  processes  can 
find  these  issues  and  also 
demonstrate  their  resolution.  Test 
plans  must  be  developed,  executed, 
and  include  tests  for  this  kind  of 
vulnerability. 

APP3570 

High 

The  designer  will  ensure  the 
application  does  not  allow 
command  injection. 

All  MAST  input  field  must  validate 
input.  Code  review  processes  can 
find  these  issues  and  also 
demonstrate  their  resolution.  Test 
plans  must  be  developed,  executed, 
and  include  tests  for  this  kind  of 
vulnerability. 

APP3590 

High 

The  designer  will  ensure  the 
application  does  not  have 
buffer  overflows,  use 
functions  known  to  be 
vulnerable  to  buffer 
overflows,  and  does  not  use 
signed  values  for  memory 
allocation  where  permitted 
by  the  programming 
language. 

All  MAST  input  fields  must  validate 
input.  Code  review  processes  can 
find  these  issues  and  also 
demonstrate  their  resolution.  Test 
plans  must  be  developed,  executed, 
and  include  tests  for  this  kind  of 
vulnerability. 

APP3600 

Medium 

The  designer  will  ensure  the 
application  has  no  canonical 
representation 
vulnerabilities. 

All  MAST  input  fields  must  validate 
input.  Code  review  processes  can 
find  these  issues  and  also 
demonstrate  their  resolution.  Test 
plans  must  be  developed,  executed, 
and  include  tests  for  this  kind  of 
vulnerability. 
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STIG  ID 
Severity 

Requirement  from  ASD 
STIG 

Mitigation 

APP3620 

Medium 

The  designer  will  ensure  the 
application  does  not  disclose 
unnecessary  information  to 
users. 

MAST  will  present  users  with  stack 
traces  on  some  errors.  Code  review 
processes  can  find  these  issues  and 
also  demonstrate  their  resolution. 
Corrections  include  updating  try- 
catch  blocks  to  address  errors  more 
cleanly  and  ensuring  all  potential 
errors  are  caught. 

APP3630 

Medium 

The  designer  will  ensure  the 
application  is  not  vulnerable 
to  race  conditions. 

Code  review  processes  find  these 
issues  and  also  demonstrate  their 
resolution.  Test  plans  must  be 
developed,  executed,  and  include 
tests  for  this  kind  of  vulnerability. 

APP3670 

Medium 

The  designer  will  ensure  the 
application  has  a  capability 
to  display  the  user’s  time  and 
date  of  the  last  change  in 
data  content. 

Develop  robust  logging  for  MAST. 

With  the  current  minimal  logging 
capabilities,  MAST  cannot  display 
the  user’s  time  and  date  of  the  last 
change  in  data  content. 

APP3680 

Medium 

The  designer  will  ensure  the 
application  design  includes 
audits  on  all  access  to  need- 
to-know  information  and  key 
application  events. 

Develop  robust  logging  for  MAST. 
Mast  has  only  minimal  logging 
capabilities  and  cannot  support 
audits  on  access  to  need-to-know 
information  and  events. 

APP3690 

Medium 

The  designer  and  IAO  will 
ensure  the  audit  trail  is 
readable  only  by  the 
application  and  auditors  and 
protected  against 
modification  and  deletion  by 
unauthorized  individuals. 

Develop  robust  logging  for  MAST. 
Mast  has  only  minimal  logging 
capabilities. 

APP3960 

Medium 

The  designer  will  ensure  the 
application  is  compliant  with 
all  DOD  IT  Standards 

Registry  (DISR)  IPv6 
profiles. 

Java  has  IPv6  support  built  in  and 
will  attempt  to  handle  IPv6/IPv4 
issues  seamlessly,  however 
application  test  plans  need  to  be 
created  and  executed  to  ensure  the 
compatibility. 

APP3970 

Medium 

The  designer  will  ensure 
supporting  application 
services  and  interfaces  have 
been  designed,  or  upgraded 
for,  IPv6  transport. 

Java  has  IPv6  support  built  in  and 
will  attempt  to  handle  IPv6/IPv4 
issues  seamlessly,  however 
application  test  plans  need  to  be 
created  and  executed  to  ensure  the 
compatibility. 
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STIG  ID 
Severity 

Requirement  from  ASD 
STIG 

Mitigation 

APP3980 

Medium 

The  designer  will  ensure  the 
application  is  compliant  with 
IPv6  multicast  addressing 
and  features  an  IPv6 
network  configuration 
options  as  defined  in  RFC 
4038. 

Java  has  IPv6  support  built  in  and 
will  attempt  to  handle  IPv6/IPv4 
issues  seamlessly,  however 
application  test  plans  need  to  be 
created  and  executed  to  ensure  the 
compatibility. 

APP3990 

Medium 

The  designer  will  ensure  the 
application  is  compliant  with 
the  IPv6  addressing  scheme 
as  defined  in  RFC  1884. 

Java  has  IPv6  support  built  in  and 
will  attempt  to  handle  IPv6/IPv4 
issues  seamlessly,  however 
application  test  plans  need  to  be 
created  and  executed  to  ensure  the 
compatibility. 

APP4030 

Medium 

The  Release  Manager  will 
develop  an  SCM  plan 
describing  the  configuration 
control  and  change 
management  process  of 
objects  developed  and  the 
roles  and  responsibilities  of 
the  organization. 

Develop  a  SCM  plan  for  MAST.  It 
must  describe  configuration  control 
and  change  management  process 

APP4040 

Medium 

The  Release  Manager  will 
establish  a  Configuration 
Control  Board  (CCB)  that 
meets  at  least  every  release 
cycle,  for  managing  the  CM 
process. 

Establish  a  CCB  to  support  and 
execute  the  SCM  for  MAST. 

APP4050 

Medium 

The  release  manager  must 
ensure  application  files  are 
cryptographically  hashed 
prior  to  deploying  to  DOD 
operational  networks. 

Within  the  SCM,  create  processes  to 
hash  new  releases  of  MAST  Also, 
ensure  that  those  hashes  are 
included  in  MAST  releases. 

APP5040 

Medium 

The  Test  Manager  will 
ensure  the  changes  to  the 
application  are  assessed  for 

IA  and  accreditation  impact 
prior  to  implementation. 

MAST  does  not  have  a  documented 
test  program.  In  developing  that 
program,  include  the  development 
and  execution  IA  tests  for  MAST. 

APP5050 

Medium 

The  Test  Manager  will 
ensure  tests  plans  and 
procedures  are  created  and 
executed  prior  to  each 
release  of  the  application  or 
updates  to  system  patches. 

Develop  a  test  program  for  MAST. 
Ensure,  as  part  of  the  program,  that 
tests  prior  to  release. 
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STIG  ID 
Severity 

Requirement  from  ASD 
STIG 

Mitigation 

APP5060 

Medium 

The  Test  Manager  will 
ensure  test  procedures  are 
created  and  at  least  annually 
executed  to  ensure  system 
initialization,  shutdown,  and 
aborts  are  configured  to 
ensure  the  system  remains 
in  a  secure  state. 

Develop  a  test  program  for  MAST. 
Ensure,  as  part  of  the  program,  that 
tests  are  included  that  the  system 
remains  in  a  secure  state,  through 
shutdown,  startup,  and  other  overall 
system  state  changes. 

APP5080 

Medium 

The  Test  Manager  will 
ensure  a  code  review  is 
performed  before  the 
application  is  released. 

Develop  a  test  program  for  MAST. 
Ensure,  as  part  of  the  program,  that 
code  review  is  included. 

APP5090 

Medium 

The  Test  Manager  will 
ensure  flaws  found  during  a 
code  review  are  tracked  in  a 
defect  tracking  system. 

Develop  a  test  program  for  MAST. 
Ensure,  as  part  of  the  program,  that 
findings  from  code  review  are 
tracked  and  resolved. 

APP5100 

Medium 

The  IAO  will  ensure  active 
vulnerability  testing  is 
performed. 

Develop  and  execute  a  vulnerability 
management  program. 

APP5110 

Medium 

The  Test  Manager  will 
ensure  security  flaws  are 
fixed  or  addressed  in  the 
project  plan. 

Develop  a  test  program  for  MAST. 
Ensure,  as  part  of  the  program,  that 
security  flaws  are  fixed. 

APP6010 

Medium 

The  IAO  will  ensure  if  an 
application  is  designated 
critical,  the  application  is  not 
hosted  on  a  general  purpose 
machine. 

MAST  development  platforms  and 
environments  require  an  IAO  and  IA 
processes  to  ensure  secure 
operation.  Establish  IAO  to  corrected 
findings. 

APP6030 

Medium 

The  IAO  will  ensure 
unnecessary  services  are 
disabled  or  removed. 

MAST  development  platforms  and 
environments  require  an  IAO  and  IA 
processes  to  ensure  secure 
operation.  Establish  IAO  to  corrected 
findings. 

APP6040 

Medium 

The  IAO  will  ensure  at  least 
one  application  administrator 
has  registered  to  receive 
update  notifications,  or 
security  alerts,  when 
automated  alerts  are 
available. 

MAST  development  platforms  and 
environments  require  an  IAO  and  IA 
processes  to  ensure  secure 
operation.  Establish  IAO  to  corrected 
findings. 
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STIG  ID 
Severity 

Requirement  from  ASD 
STIG 

Mitigation 

APP6050 

Medium 

The  IAO  will  ensure  the 
system  and  installed 
applications  have  current 
patches,  security  updates, 
and  configuration  settings. 

MAST  development  platforms  and 
environments  require  an  IAO  and  IA 
processes  to  ensure  secure 
operation.  Establish  IAO  to  corrected 
findings. 

APP6060 

High 

The  IAO  will  ensure  the 
application  is 
decommissioned  when 
maintenance  or  support  is  no 
longer  available. 

MAST  development  platforms  and 
environments  require  an  IAO  and  IA 
processes  to  ensure  secure 
operation.  Establish  IAO  to  corrected 
findings. 

APP6080 

Medium 

The  IAO  will  ensure 
protections  against  DoS 
attacks  are  implemented. 

MAST  development  platforms  and 
environments  require  an  IAO  and  IA 
processes  to  ensure  secure 
operation.  Establish  IAO  to  corrected 
findings. 

APP6140 

Medium 

The  IAO  will  ensure 
application  audit  trails  are 
retained  for  at  least  1  year 
for  applications  without  SAMI 
data,  and  5  years  for 
applications  including  SAMI 
data. 

MAST  development  platforms  and 
environments  require  an  IAO  and  IA 
processes  to  ensure  secure 
operation.  Establish  IAO  to  corrected 
findings. 

APP6160 

Medium 

The  IAO  will  ensure  recovery 
procedures  and  technical 
system  features  exist  so 
recovery  is  performed  in  a 
secure  and  verifiable 
manner.  The  IAO  will 
document  circumstances 
inhibiting  a  trusted  recovery. 

MAST  development  platforms  and 
environments  require  an  IAO  and  IA 
processes  to  ensure  secure 
operation.  Establish  IAO  to  corrected 
findings. 

APP6170 

Medium 

The  IAO  will  ensure  back-up 
copies  of  the  application 
software  are  stored  in  a  fire¬ 
rated  container  and  not 
collocated  with  operational 
software. 

MAST  development  platforms  and 
environments  require  an  IAO  and  IA 
processes  to  ensure  secure 
operation.  Establish  IAO  to  corrected 
findings. 

APP6180 

Medium 

The  IAO  will  ensure 
procedures  are  in  place  to 
assure  the  appropriate 
physical  and  technical 
protection  of  the  backup  and 
restoration  of  the  application. 

MAST  development  platforms  and 
environments  require  an  IAO  and  IA 
processes  to  ensure  secure 
operation.  Establish  IAO  to  corrected 
findings. 
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STIG  ID 
Severity 

Requirement  from  ASD 
STIG 

Mitigation 

APP6190 

Medium 

The  IAO  will  ensure  data 
backup  is  performed  at 
required  intervals  in 
accordance  with  DOD  policy. 

MAST  development  platforms  and 
environments  require  an  IAO  and  IA 
processes  to  ensure  secure 
operation.  Establish  IAO  to  corrected 
findings. 

APP6200 

Medium 

The  IAO  will  ensure  a 
disaster  recovery  plan  exists 
in  accordance  with  DOD 
policy  based  on  the  Mission 
Assurance  Category  (MAC). 

MAST  development  platforms  and 
environments  require  an  IAO  and  IA 
processes  to  ensure  secure 
operation.  Establish  IAO  to  corrected 
findings. 

K.  SUMMARY 

In  this  chapter,  a  threat  model  for  MAST  was  developed  and  then  utilized 
to  propose  mitigations  to  vulnerabilities  in  MAST’s  architecture.  Particular  areas 
of  concern  were  determined  to  be  in  Application  Tier-to-Tier  Trust  and  Simware 
Trust.  Following  the  threat  model,  findings  that  would  not  be  apparent  in  a  threat 
model  are  enumerated  along  with  their  corresponding  mitigations.  The  next 
chapter  concludes  the  research  and  discusses  future  research  opportunities. 
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VI.  CONCLUSION  AND  FUTURE  WORK 


This  chapter  discusses  conclusions  from  this  research  and  opportunities 
for  future  work. 

A.  CONCLUSION 

This  thesis  was  driven  by  the  need  to  determine  the  weaknesses  and 
vulnerabilities  within  MAST  and  steps  to  be  taken  to  prepare  it  for  deployment  on 
an  operational  platform,  focusing  specifically  on  security  concerns. 

The  SCA  was  executed  based  on  [1],  the  primary  guidance  document  for 
DOD  secure  application  development  and  deployment.  Following  the  SCA,  a  risk 
analysis  was  conducted  via  threat  modeling  methodology.  The  threat  model 
defines  vulnerabilities  to  confidentiality,  availability,  and  integrity  and  supported 
mitigations  approaches  to  resolve  those  findings. 

In  Chapter  IV,  the  SCA  determined  that  MAST  has  several  CAT  I,  CAT  II 
and  CATII  findings.  Should  these  findings  be  left  unaddressed,  MAST  would  not 
be  able  to  acquire  an  ATO. 

In  Chapter  V,  the  threat  model  determined  critical  risk  areas  in  which 
future  efforts  should  be  targeted  to  get  MAST  ready  for  deployment. 

At  this  stage  in  its  development,  MAST  is  not  ready  for  deployment  in  an 
operation  environment,  beyond  strictly  limited  and  controlled  test  events.  This 
research  has  shown  that  MAST  has  several  major  rectifications  necessary  to 
operate  securely. 

Once  properly  hardened,  MAST  will  provide  unique  opportunity  for 
advancing  information  system  operators’  cyber  readiness.  MAST  shows  great 
promise  in  its  utilization  as  a  training  device  to  ready  the  cyber  workforce  to 
manage  real-life  cyber  risks. 
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B.  FUTURE  WORK 


The  SCA  has  identified  several  opportunities  for  improvement  to  MAST, 
following  what  has  been  done  in  this  thesis,  particularly  to  implement  vulnerability 
mitigations.  Each  of  the  vulnerabilities  identified  by  this  research  is  significant 
enough  to  warrant  future  research  and  development. 

1.  Application  Tier-to-Tier  Trust 

The  Tier-to-Tier  Trust  problem  requires  significant  research  and 
development  in  order  to  determine  how  to  effectively  meet  confidentiality  and 
integrity  needs.  Key-exchange  for  encryption  between  tiers  and  authentication 
represent  significant  challenges  that  warrant  further  research. 

2.  Simware  Trust 

In  order  to  deploy  a  complete  code  signing  and  validation  program  MAST 
may  require  significant  extensions.  Success  of  a  secure  distribution  system 
would  require  a  single  source  for  Simware  in  order  to  protect  signing  signatures. 
Because  of  the  intensity  of  change  to  MAST  to  support  this,  there  is  great 
opportunity  in  pursuing  this  researching  and  developing  this  solution. 

3.  Additional  SCA 

This  SCA  was  based  on  version  3,  release  8  of  the  ASD  STIG  [1],  which 
was  the  current  release  when  this  research  began.  The  ASD  STIG  has  been 
updated  twice  while  this  research  was  underway  and  upon  completion,  the  ASD 
STIG  was  at  version  3,  release  10.  As  secure  development  practices  are 
constantly  evolving  and  improving,  these  updates  are  to  be  expected.  If  the 
mitigations  proposed  in  this  research  are  implemented,  a  very  different  and  much 
more  secure  MAST  would  result,  creating  the  opportunity  to  research  another 
SCA. 
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APPENDIX.  DISA  APPLICATION  SECURITY  STIG  AREAS 


Table  18.  DISA  Application  Security  STIG  Areas,  shows  what  focus  areas 
each  test  from  the  Application  Security  and  Development  STIG  apply  to.  An  “X” 
indicates  that  a  test  applies  to  that  particular  focus  area. 


Table  18.  DISA  Application  Security  STIG  Areas,  after  [1] 


Vuln  ID 

Rule  Title 

IA  Controls 

V-6127 

The  designer  will  ensure  applications 

requiring  user  authentication  are  PK- 

enabled  and  are  designed  and 

implemented  to  support  hardware  tokens 

(e.g.,  CAC  forNIPRNet). 

IATS-1 ,  IATS-2 

V-6128 

The  designer  and  IAO  will  ensure  PK- 

enabled  applications  are  designed  and 

implemented  to  use  approved  credentials 

authorized  under  the  DOD  PKI  program. 

IATS-1,  IATS-2 

V-6129 

The  designer  will  ensure  the  application 

using  PKI  validates  certificates  for 

expiration,  confirms  origin  is  from  a  DOD 

authorized  CA,  and  verifies  the  certificate 

has  not  been  revoked  by  CRL  or  OCSP, 

and  CRL  cache  (if  used)  is  updated  at 

least  daily. 

IATS-1,  IATS-2 

V-6130 

The  designer  will  ensure  the  application 

has  the  capability  to  require  account 

passwords  that  conform  to  DOD  policy. 

IAIA-1 

V-6131 

The  designer  will  ensure  the  application 

prevents  the  creation  of  duplicate 

accounts. 

IAIA-1 

V-6132 

The  IAO  will  ensure  all  user  accounts  are 

IAAC-1 ,  IAIA-1 
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Deployment 


Vuln  ID 


Rule  Title 


IA  Controls 


V-6133 

V-6134 

V-6135 

V-6136 

V-6137 

V-6138 

V-6139 


disabled  which  are  authorized  to  have 
access  to  the  application  but  have  not 
authenticated  within  the  past  35  days. 

The  IAO  will  ensure  unnecessary  built-in 
application  accounts  are  disabled. 

The  IAO  will  ensure  default  passwords 
are  changed. 

The  designer  will  ensure  the  appropriate 
cryptography  is  used  to  protect  stored 
DOD  information  if  required  by  the 
information  owner. 

The  designer  will  ensure  data  transmitted 
through  a  commercial  or  wireless  network 
is  protected  using  an  appropriate  form  of 
cryptography. 

The  designer  will  ensure  the  application 
uses  the  Federal  Information  Processing 
Standard  (FIPS)  140-2  validated 
cryptographic  modules  and  random 
number  generator  if  the  application 
implements  encryption,  key  exchange, 
digital  signature,  and  hash  functionality. 

The  designer  will  ensure  the  application 
design  includes  audits  on  all  access  to 
need-to-know  information  and  key 
application  events. 

The  designer  will  ensure  the  application 
has  a  capability  to  notify  an  administrator 
when  audit  logs  are  nearing  capacity  as 


specified  in  the  system  documentation. 


ECTP-1 


V-6140 


The  designer  and  IAO  will  ensure  the 
audit  trail  is  readable  only  by  the 
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x 


x 


Deployment 


application  and  auditors  and  protected 
against  modification  and  deletion  by 
unauthorized  individuals. 


The  designer  will  ensure  access  control 
mechanisms  exist  to  ensure  data  is 
accessed  and  changed  only  by 
authorized  personnel. 


The  designer  will  ensure  all  access 
authorizations  to  data  are  revoked  prior  to 
initial  assignment,  allocation  or 
reallocation  to  an  unused  state. 


The  designer  will  ensure  the  application 
executes  with  no  more  privileges  than 
necessary  for  proper  operation. 


The  designer  will  ensure  the  application 
provides  a  capability  to  limit  the  number 
of  logon  sessions  per  user  and  per 
application. 


If  the  application  contains  classified  data, 
the  Program  Manager  will  ensure  a 
Security  Classification  Guide  exists 
containing  data  elements  and  their 
classification. 


The  designer  will  ensure  the  application 
has  the  capability  to  mark 
sensitive/classified  output  when  required. 


The  Test  Manager  will  ensure  the 
application  does  not  modify  data  files 
outside  the  scope  of  the  application. 


The  designer  will  ensure  threat  models 
are  documented  and  reviewed  for  each 
application  release  and  updated  as 


IA  Controls 


DCSQ-1 
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Vuln  ID 


Rule  Title 


IA  Controls 


V-6149 

V-6150 

V-6151 

V-6152 

V-6153 

V-6154 

V-6155 

V-6156 


required  by  design  and  functionality 
changes  or  new  threats  are  discovered. 

The  designer  will  ensure  the  application 
does  not  contain  source  code  that  is 
never  invoked  during  operation,  except 
for  software  components  and  libraries 
from  approved  third-party  products. 

The  Designer  will  ensure  the  application 
does  not  store  configuration  and  control 
files  in  the  same  directory  as  user  data. 

The  IAO  will  ensure  unnecessary 
services  are  disabled  or  removed. 

The  designer  will  ensure  the  application 
is  capable  of  displaying  a  customizable 
click-through  banner  at  logon  which 
prevents  further  activity  on  the 
information  system  unless  and  until  the 
user  executes  a  positive  action  to 
manifest  agreement  by  clicking  on  a  box 
indicating  ‘OK.” 

The  designer  will  ensure  the  application 
removes  authentication  credentials  on 
client  computers  after  a  session 
terminates. 

The  designer  will  ensure  the  application 
is  organized  by  functionality  and  roles  to 
support  the  assignment  of  specific  roles 
to  specific  application  functions. 

The  designer  will  ensure  the  application 
provides  a  capability  to  terminate  a 
session  and  log  out. 

The  designer  will  ensure  the  application 
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Deployment 


Vuln  ID 


Rule  Title 


IA  Controls 


V-6157 


V-6158 


V-6159 


V-6160 


V-6161 


V-6162 


V-6163 


V-6164 


V-6165 


does  not  contain  embedded 
authentication  data. 

The  designer  will  ensure  the  application 
does  not  contain  invalid  URL  or  path 
references. 

The  designer  will  ensure  the  application 
only  embeds  mobile  code  in  email  which 
does  not  execute  automatically  when  the 
user  opens  the  email  body  or  attachment. 

The  designer  will  ensure  unsigned 
Category  1 A  mobile  code  is  not  used  in 
the  application  in  accordance  with  DOD 
policy. 

The  designer  will  ensure  unsigned 
Category  2  mobile  code  executing  in  a 
constrained  environment  has  no  access 
to  local  system  and  network  resources. 

The  designer  will  ensure  signed  Category 
1 A  and  Category  2  mobile  code  signature 
is  validated  before  executing. 

The  designer  will  ensure  uncategorized 
or  emerging  mobile  code  is  not  used  in 
applications. 

The  Designer  will  ensure  the  application 
removes  temporary  storage  of  files  and 
cookies  when  the  application  is 
terminated. 

The  designer  will  ensure  the  application 
validates  all  input. 

The  designer  will  ensure  the  application 
does  not  have  buffer  overflows,  use 
functions  known  to  be  vulnerable  to  buffer 
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Vuln  ID 

V-6166 

V-6167 

V-6168 

V-6169 

V-6170 

V-6171 

V-6172 

V-6173 


Rule  Title 

overflows,  and  does  not  use  signed 
values  for  memory  allocation  where 
permitted  by  the  programming  language. 

The  designer  will  ensure  the  application 
is  not  subject  to  error  handling 
vulnerabilities. 

The  designer  will  ensure  application 
initialization,  shutdown,  and  aborts  are 
designed  to  keep  the  application  in  a 
secure  state. 

The  designer  will  ensure  applications 
requiring  server  authentication  are  PK- 
enabled. 

The  Program  Manager  and  designer  will 
ensure  the  application  design  complies 
with  the  DOD  Ports  and  Protocols 
guidance. 

The  Program  Manager  and  designer  will 
ensure  any  IA,  or  IA  enabled,  products 
used  by  the  application  are  NIAP 
approved  or  in  the  NIAP  approval 
process. 

The  IAO  will  ensure  recovery  procedures 
and  technical  system  features  exist  so 
recovery  is  performed  in  a  secure  and 
verifiable  manner.  The  IAO  will 
document  circumstances  inhibiting  a 
trusted  recovery. 

The  IAO  will  ensure  data  backup  is 
performed  at  required  intervals  in 
accordance  with  DOD  policy. 

The  IAO  will  ensure  application  audit 
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Vuln  ID 


Rule  Title 


IA  Controls 


V-6174 


V-6197 


V-6198 


V-7013 


V-16773 


V-16775 


trails  are  retained  for  at  least  1  year  for 
applications  without  SAMI  data,  and  5 
years  for  applications  including  SAMI 
data. 

The  IAO  will  ensure  production  database 
exports  have  database  administration 
credentials  and  sensitive  data  removed 
before  releasing  the  export. 

The  Program  Manager  will  ensure  a 
System  Security  Plan  (SSP)  is 
established  to  describe  the  technical, 
administrative,  and  procedural  IA 
program  and  policies  governing  the  DOD 
information  system,  and  identifying  all  IA 
personnel  and  specific  IA  requirements 
and  objectives. 

The  Program  Manager  and  IAO  will 
ensure  development  systems,  build 
systems,  test  systems,  and  all 
components  comply  with  all  appropriate 
DOD  STIGs,  NSA  guides,  and  all 
applicable  DOD  policies.  The  Test 
Manager  will  ensure  both  client  and 
server  machines  are  STIG  compliant. 

The  designer  will  create  and  update  the 
Design  Document  for  each  release  of  the 
application. 

The  Program  Manager  will  provide  an 
Application  Configuration  Guide  to  the 
application  hostingproviders  to  include  a 
list  of  all  potential  hosting  enclaves  and 
connection  rules  and  requirements. 

The  Program  Manager  will  ensure  the 
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Deployment 


Vuln  ID 


Rule  Title 


IA  Controls 


V-16776 


V-16777 


V-16778 


V-16779 


V-16780 


V-16781 


system  has  been  assigned  specific  MAC 
and  confidentiality  levels. 

The  Program  Manager  will  ensure  the 
development  team  follows  a  set  of  coding 
standards. 

The  Program  Manager  will  ensure  COTS 
lAand  IA  enabled  products,  comply  with 
N I AP/NSA  endorsed  protection  profiles. 

The  Program  Manager  will  document  and 
obtain  DAA  risk  acceptance  for  all  public 
domain,  shareware,  freeware,  and  other 
software  products/libraries  with  both  (1) 
no  source  code  to  review,  repair,  and 
extend,  and  (2)  limited  or  no  warranty, 
when  such  products  are  required  for 
mission  accomplishment. 

The  Program  Manager  and  designer  will 
ensure  the  application  is  registered  with 
the  DOD  Ports  and  Protocols  Database. 

The  Program  Manager  will  ensure  all 
levels  of  program  management, 
designers,  developers,  and  testers 
receive  the  appropriate  security  training 
pertaining  to  their  job  function. 

The  Program  Manager  will  ensure  a 
vulnerability  management  process  is  in 
place  to  include  ensuring  a  mechanism  is 
in  place  to  notify  users,  and  users  are 
provided  with  a  means  of  obtaining 


security  updates  for  the  application. 


V-16782 


The  Program  Manager  will  ensure  a 
security  incident  response  process  for  the 
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Deployment 


Vuln  ID 


Rule  Title 


IA  Controls 


V-16783 


V-16784 


V-16785 


V-16786 


V-16787 


V-16788 


V-16789 


application  is  established  that  defines 
reportable  incidents  and  outlines  a 
standard  operating  procedure  for  incident 
response  to  include  Information 
Operations  Condition  (INFOCON). 

The  Program  Manager  will  ensure 
procedures  are  implemented  to  assure 
physical  handling  and  storage  of 
information  is  in  accordance  with  the 
data’s  sensitivity. 

The  designer  will  ensure  the  user 
interface  services  are  physically  or 
logically  separated  from  data  storage  and 
management  services. 

The  designer  will  ensure  the  application 
supports  detection  and/or  prevention  of 
communication  session  hijacking. 

The  designer  will  ensure  the  application 
installs  with  unnecessary  functionality 
disabled  by  default. 

The  designer  will  ensure  the  application 
follows  the  secure  failure  design  principle. 

The  designer  will  ensure  the  application 
uses  encryption  to  implement  key 
exchange  and  authenticate  endpoints 
prior  to  establishing  a  communication 
channel  for  key  exchange. 

The  designer  will  ensure  private  keys  are 


accessible  only  to  administrative  users. 


V-16790 


The  designer  will  ensure  the  application 
does  not  connect  to  a  database  using 
administrative  credentials  or  other 


ECLP-1 
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Vuln  ID 


Rule  Title 


IA  Controls 


V-16791 

V-16792 

V-16793 

V-16794 

V-16795 

V-16796 

V-16797 

V-16798 


privileged  database  accounts. 

The  designer  will  ensure  transaction 
based  applications  implement  transaction 
rollback  and  transaction  journaling. 

The  designer  will  ensure  sensitive  data 
held  in  memory  is  cryptographically 
protected  when  not  in  use,  if  required  by 
the  information  owner,  and  classified  data 
held  in  memory  is  always 
cryptographically  protected  when  not  in 
use. 

The  designer  will  ensure  the  application 
properly  clears  or  overwrites  all  memory 
blocks  used  to  process  sensitive  data,  if 
required  by  the  information  owner,  and 
clears  or  overwrites  all  memory  blocks 
used  for  classified  data. 

The  designer  will  ensure  the  application 
uses  mechanisms  assuring  the  integrity 
of  all  transmitted  information  (including 
labels  and  security  parameters). 

The  designer  will  ensure  the  application 
does  not  display  account  passwords  as 
clear  text. 

The  designer  will  ensure  the  application 
transmits  account  passwords  in  an 
approved  encrypted  format. 

The  designer  will  ensure  the  application 
stores  account  passwords  in  an  approved 
encrypted  format. 

The  designer  will  ensure  the  application 
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Vuln  ID 


Rule  Title 


IA  Controls 


V-16799 


V-16800 


V-16801 


V-16802 


V-16803 


V-16804 


V-16806 


protects  access  to  authentication  data  by 
restricting  access  to  authorized  users  and 
services. 

The  designer  will  ensure  the  application 
installs  with  unnecessary  accounts 
disabled,  or  deleted,  by  default. 

The  designer  will  ensure  users’  accounts 
are  locked  after  three  consecutive 


unsuccessful  logon  attempts  within  one 
hour. 

The  designer  will  ensure  locked  users’ 
accounts  can  only  be  unlocked  by  the 
application  administrator. 

The  designer  will  ensure  the  application 
provides  a  capability  to  automatically 
terminate  a  session  and  log  out  after  a 
system  defined  session  idle  time  limit  is 
exceeded. 

The  designer  and  IAO  will  ensure 
application  resources  are  protected  with 
permission  sets  which  allow  only  an 
application  administrator  to  modify 
application  resource  configuration  files. 

The  designer  will  ensure  the  application 
does  not  rely  solely  on  a  resource  name 
to  control  access  to  a  resource. 

The  designer  will  ensure  the  web 
application  assigns  the  character  set  on 


all  web  pages. 


V-16807 


The  designer  will  ensure  the  application 
is  not  vulnerable  to  SQL  Injection,  uses 
prepared  or  parameterized  statements, 
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Vuln  ID 


Rule  Title 


IA  Controls 


V-16808 

V-16809 

V-16810 

V-16811 

V-16812 

V-16813 

V-16814 

V-16815 

V-16816 

V-16817 


does  not  use  concatenation  or 
replacement  to  build  SQL  queries,  and 
does  not  directly  access  the  tables  in  a 
database. 

The  designer  will  ensure  the  application 
is  not  vulnerable  to  integer  arithmetic 
issues. 

The  designer  will  ensure  the  application 
does  not  contain  format  string 
vulnerabilities. 

The  designer  will  ensure  the  application 
does  not  allow  command  injection. 

The  designer  will  ensure  the  application 
does  not  have  cross  site  scripting  (XSS) 
vulnerabilities. 

The  designer  will  ensure  the  application 
has  no  canonical  representation 
vulnerabilities. 

The  designer  will  ensure  the  application 
does  not  use  hidden  fields  to  control  user 
access  privileges  or  as  a  part  of  a 
security  mechanism. 

The  designer  will  ensure  the  application 
does  not  disclose  unnecessary 
information  to  users. 

The  designer  will  ensure  the  application 
is  not  vulnerable  to  race  conditions. 

The  designer  will  ensure  the  application 
supports  the  creation  of  transaction  logs 
for  access  and  changes  to  the  data. 

The  designer  will  ensure  the  application 
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Vuln  ID 


Rule  Title 


V-16818 


V-16819 


V-16820 


V-16822 


V-16823 


V-16824 


V-16825 


V-16826 


IA  Controls 


has  a  capability  to  notify  the  user  of 
important  login  information. 


The  designer  will  ensure  the  application 
has  a  capability  to  display  the  user’s  time 
and  date  of  the  last  change  in  data 
content. 


The  designer  will  ensure  development  of 
new  mobile  code  includes  measures  to 
mitigate  the  risks  identified. 


The  Release  Manager  will  ensure  the 
access  privileges  to  the  configuration 
management  (CM)  repository  are 
reviewed  every  3  months. 


The  Release  Manager  will  develop  an 
SCM  plan  describing  the  configuration 
control  and  change  management  process 
of  objects  developed  and  the  roles  and 
responsibilities  of  the  organization. 


The  Release  Manager  will  establish  a 
Configuration  Control  Board  (CCB),  that 
meets  at  least  every  release  cycle,  for 
managing  the  CM  process. 


The  Test  Manager  will  ensure  at  least 
one  tester  is  designated  to  test  for 
security  flaws  in  addition  to  functional 
testing. 


The  Test  Manager  will  ensure  the 
changes  to  the  application  are  assessed 
for  IA  and  accreditation  impact  prior  to 
implementation. 


The  Test  Manager  will  ensure  tests  plans 
and  procedures  are  created  and  executed 
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V-16827 


V-16828 


V-16829 


V-16830 


V-16831 


V-16832 


V-16833 


V-16834 


prior  to  each  release  of  the  application  or 
updates  to  system  patches. 

The  Test  Manager  will  ensure  test 
procedures  are  created  and  at  least 
annually  executed  to  ensure  system 
initialization,  shutdown,  and  aborts  are 
configured  to  ensure  the  system  remains 
in  a  secure  state. 

The  Test  Manager  will  ensure  code 
coverage  statistics  are  maintained  for 
each  release  of  the  application. 

The  Test  Manager  will  ensure  a  code 
review  is  performed  before  the  application 
is  released. 

The  Test  Manager  will  ensure  flaws 
found  during  a  code  review  are  tracked  in 
a  defect  tracking  system. 

The  IAO  will  ensure  active  vulnerability 
testing  is  performed. 

The  Test  Manager  will  ensure  security 
flaws  are  fixed  or  addressed  in  the  project 
plan. 

The  IAO  will  ensure  if  an  application  is 
designated  critical,  the  application  is  not 
hosted  on  a  general  purpose  machine. 

The  IAO  shall  ensure  if  a  DOD  STIG  or 
NSA  guide  is  not  available,  a  third-party 
product  will  be  configured  by  the  following 
in  descending  order  as  available:  1) 
commercially  accepted  practices,  (2) 
independent  testing  results,  or  (3)  vendor 
literature. 
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Vuln  ID 

Rule  Title 

IA  Controls 

V-16835 

The  IAO  will  ensure  at  least  one 

application  administrator  has  registered  to 

receive  update  notifications,  or  security 

alerts,  when  automated  alerts  are 

available. 

DCCT-1 

V-16836 

The  IAO  will  ensure  the  system  and 

installed  applications  have  current 

patches,  security  updates,  and 

configuration  settings. 

DCCT-1 

V-16837 

The  IAO  will  ensure  the  application  is 

decommissioned  when  maintenance  or 

support  is  no  longer  available. 

DCSD-1 , 

ECSC-1 

V-16838 

Procedures  are  not  in  place  to  notify 

users  when  an  application  is 

decommissioned. 

DCSD-1 

V-16839 

The  IAO  will  ensure  protections  against 

DoS  attacks  are  implemented. 

DCSQ-1 

V-16840 

The  IAO  will  ensure  the  system  alerts  an 

administrator  when  low  resource 

conditions  are  encountered. 

ECAT-2 

V-16841 

The  IAO  will  review  audit  trails 

periodically  based  on  system 

documentation  recommendations  or 

immediately  upon  system  security  events. 

ECCD-2 

V-16842 

The  IAO  will  report  all  suspected 

violations  of  IA  policies  in  accordance 

with  DOD  information  system  IA 

procedures. 

ECAT-2 

V-16843 

The  IAO  will  ensure,  for  classified 

systems,  application  audit  trails  are 

continuously  and  automatically 

monitored,  and  alerts  are  provided 

ECAT-2 

“  u/  I-  “ 

O)  0)0 
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Vuln  ID 


Rule  Title 


IA  Controls 


V-16844 


V-16845 


V-16846 


V-16847 


V-16848 


V-16849 


V-16850 


V-19687 


immediately  when  unusual  or 
inappropriate  activity  is  detected. 

The  IAO  will  ensure  back-up  copies  of 
the  application  software  are  stored  in  a 
fire-rated  container  and  not  collocated 
with  operational  software. 

The  IAO  will  ensure  procedures  are  in 
place  to  assure  the  appropriate  physical 
and  technical  protection  of  the  backup 
and  restoration  of  the  application. 

The  IAO  will  ensure  a  disaster  recovery 
plan  exists  in  accordance  with  DOD 
policy  based  on  the  Mission  Assurance 
Category  (MAC). 

The  IAO  will  ensure  an  account 
management  process  is  implemented, 
verifying  only  authorized  users  can  gain 
access  to  the  application,  and  individual 
accounts  designated  as  inactive, 
suspended,  or  terminated  are  promptly 
removed. 

The  IAO  will  ensure  passwords 
generated  for  users  are  not  predictable 
and  comply  with  the  organization’s 
password  policy. 

The  IAO  will  ensure  the  application’s 
users  do  not  use  shared  accounts. 

The  IAO  will  ensure  connections  between 
the  DOD  enclave  and  the  Internet  or 
other  public  or  commercial  wide  area 
networks  require  a  DMZ. 

The  IAO  will  ensure  web  servers  are  on 
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Vuln  ID 


Rule  Title 


IA  Controls 


V-19688 

V-19689 

V-19690 

V-19691 

V-19692 

V-19693 

V-19694 

V-19695 


logically  separate  network  segments  from 
the  application  and  database  servers  if  it 
is  a  tiered  application. 

The  designer  and  the  IAO  will  ensure 
physical  operating  system  separation  and 
physical  application  separation  is 
employed  between  servers  of  different 
data  types  in  the  web  tier  of  Increment 
1/Phase  1  deployment  of  the  DOD  DMZ 
for  Internet-facing  applications. 

The  designer  will  ensure  web  services 
are  designed  and  implemented  to 
recognize  and  react  to  the  attack  patterns 
associated  with  application-level  DoS 
attacks. 

The  designer  will  ensure  the  web  service 
design  includes  redundancy  of  critical 
functions. 

The  designer  will  ensure  web  service 
design  of  critical  functions  is  implemented 
using  different  algorithms  to  prevent 
similar  attacks  from  forming  a  complete 
application  level  DoS. 

The  designer  will  ensure  web  services 
are  designed  to  prioritize  requests  to 
increase  availability  of  the  system. 

The  designer  will  ensure  execution  flow 
diagrams  are  created  and  used  to 
mitigate  deadlock  and  recursion  issues. 

The  IAO  will  ensure  an  XML  firewall  is 
deployed  to  protect  web  services. 

The  designer  will  ensure  web  services 
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V-19696 


V-19697 


V-19698 


V-19699 


V-19700 


V-19701 


V-19702 


V-19703 


V-19704 


provide  a  mechanism  for  detecting 
resubmitted  SOAP  messages. 

The  designer  and  IAO  will  ensure  digital 
signatures  exist  on  UDDI  registry  entries 
to  verify  the  publisher. 

The  designer  and  IAO  will  ensure  UDDI 
versions  are  used  supporting  digital 
signatures  of  registry  entries. 

The  designer  and  IAO  will  ensure  UDDI 
publishing  is  restricted  to  authenticated 
users. 

The  IAO  will  ensure  web  service  inquiries 
to  UDDI  provide  read-only  access  to  the 
registry  to  anonymous  users. 

The  IAO  will  ensure  if  the  UDDI  registry 
contains  sensitive  information  and  read 
access  to  the  UDDI  registry  is  granted 
only  to  authenticated  users. 

The  designer  will  ensure  SOAP 
messages  requiring  integrity,  sign  the 
following  message  elements:-Message 
ID-Service  Request-Timestamp-SAML 
Assertion  (optionally  included  in 
messages) 

The  designer  will  ensure  when  using  WS- 
Security,  messages  use  timestamps  with 
creation  and  expiration  times. 

The  designer  will  ensure  validity  periods 
are  verified  on  all  messages  using  WS- 
Security  or  SAML  assertions. 

The  designer  shall  ensure  each  unique 
asserting  party  provides  unique  assertion 
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Rule  Title 


IA  Controls 


V-19705 

V-19706 

V-19707 

V-19708 

V-19709 

V-21498 

V-21500 

V-21519 

V-22028 


ID  references  for  each  SAML  assertion. 

The  designer  shall  ensure  encrypted 
assertions,  or  equivalent  confidentiality 
protections,  when  assertion  data  is 
passed  through  an  intermediary,  and 
confidentiality  of  the  assertion  data  is 
required  to  pass  through  the  intermediary. 

The  designer  will  ensure  the  application 
is  compliant  with  all  DOD  IT  Standards 
Registry  (DISR)  IPv6  profiles. 

The  designer  will  ensure  supporting 
application  services  and  interfaces  have 
been  designed,  or  upgraded  for,  IPv6 
transport. 

The  designer  will  ensure  the  application 
is  compliant  with  IPv6  multicast 
addressing  and  features  an  IPv6  network 
configuration  options  as  defined  in  RFC 
4038. 

The  designer  will  ensure  the  application 
is  compliant  with  the  IPv6  addressing 
scheme  as  defined  in  RFC  1884. 

The  designer  will  ensure  the  application 
is  not  vulnerable  to  XML  Injection. 

The  designer  will  ensure  the  application 
does  not  have  CSRF  vulnerabilities. 

The  Program  Manager  will  ensure  all 
products  are  supported  by  the  vendor  or 
the  development  team. 

The  designer  shall  use  the  NotOnOrAfter 
property  when  using  the 
<SubjectConfirmation>  element  in  a 
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SAML  assertion. 


The  designer  shall  use  both  the 
<NotBefore>  and  <NotOnOrAfter> 
V-22029  elements  or  <OneTimeUse>  element 

when  using  the  <Conditions>  element  in 
a  SAML  assertion. 


The  designer  will  ensure  the  asserting 
party  uses  FIPS  approved  random 
V-22030  numbers  in  the  generation  of 

Sessionlndex  in  the  SAML  element 
AuthnStatement. 


The  designer  shall  ensure  messages  are 
V-22031  encrypted  when  the  Sessionlndex  is  tied 
to  privacy  data. 


The  designer  shall  ensure  if  a 
OneTimeUse  element  is  used  in  an 
V-22032  assertion,  there  is  only  one  used  in  the 
Conditions  element  portion  of  an 
assertion. 


The  release  manager  must  ensure 

V  47163  aPP^cat'on  ^es  are  cryptographically 
hashed  prior  to  deploying  to  DOD 
operational  networks. 
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